Konkret geht es um die Dekodierung eines Drehgeber mit Rastpunkten bei den Schaltkontaktzuständen /offen-offen/ und bei /geschlossen-geschlossen/. Für den step-Parameter bei encode_read() wäre demnach 2 zu wählen.
Im Anhang befindet sich ein Bild, das die encode_read(2)-Werte bei künstlichen Schaltkontaktdaten zeigt. Die Rastpunkte sind durch blaue vertikale Linien markiert und die Position wird von der horizontalen blauen Linie angezeigt. Die rote (step=1) und grüne Linie (step=4) zeigen zum Vergleich die Position bei anderen Step-Werten.
Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die Position sobald beide Kontakte geöffnet sind - das ist korrekt. Beim anschließenden Schließen des ersten Kontakts (Störung) springt die Position wieder zurück - das ist unerwartet. Aus meiner Sicht hätte das nur beim Zustand /geschlossen-geschlossen/ passieren dürfen.
Warum ist das Verhalten korrekt? (Oder verwende ich den Dekoder falsch?)
Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die
Position sobald beide Kontakte geöffnet sind - das ist korrekt. Beim
anschließenden Schließen des ersten Kontakts (Störung) springt die
Position wieder zurück - das ist unerwartet. Aus meiner Sicht hätte das
nur beim Zustand /geschlossen-geschlossen/ passieren dürfen.
Warum ist das Verhalten korrekt?
Weil das genau das ist, was bei einem Richtungswechsel des Encoders tatsächlich passiert und auch passieren muss.
(Oder verwende ich den Dekoder falsch?)
Ja. Du musst einfach dafür sorgen, dass es keine Störungen gibt, bzw. sie nicht den Eingang erreichen. Das ist Hardware. Pullup-Widerstände verringern und/oder mit einem kleinen Kondensator nach Masse abblocken.
Weil das genau das ist, was bei einem Richtungswechsel des Encoders
tatsächlich passiert und auch passieren muss.
Der Zustand /offen-offen/ und der Zustand /geschlossen-geschlossen/ definieren eine Rastenposition. Die beiden anderen Zustände definieren keine Position.
Ja. Du musst einfach dafür sorgen, dass es keine Störungen gibt, bzw.
sie nicht den Eingang erreichen. Das ist Hardware.
Warum ist das unbedingt Hardware?
Der Geber hat definierte Rastpunkte und dort ist alles gut. Der Rest kann herausgefiltert werden, bevor der Zustand weitergereicht wird.
Ja. Du musst einfach dafür sorgen, dass es keine Störungen gibt, bzw.
sie nicht den Eingang erreichen. Das ist Hardware.
Warum ist das unbedingt Hardware?
Weil Störungsbursts den Decoder durcheinander bringen können. Nur Einzelstörungen kann man per Software filtern. Aber: wo eine Einzelstörung herkommt, kann auch ein Burst herkommen. Also sorgt man sinnvollerweise dafür, dass sowas den Pin erst garnicht erreicht.
Der Geber hat definierte Rastpunkte und dort ist alles gut. Der Rest
kann herausgefiltert werden, bevor der Zustand weitergereicht wird.
Die Elektronik weiß rein garnichts von irgendwelchen Rastpunkten. Und auch die Software weiß das nicht wirklich. Sie hat keine Möglichkeit zur Erfassung der Rastpunkte.
Natürlich muss die Position zurückspringen sonst würde sie beim erneuten
öffnen des Kontakts schon um 2 weiter schalten.
Wenn sich die Position auf Raste 3 geändert hat, dann kann sie sich nur beim Zustand /geschlossen-geschlossen/ wieder ändern. Ein erneutes /offen-offen/ beim Kontaktzustand hätte keine fehlerhafte Wirkung, weil der Rastenzustand bereits /offen-offen/ ist.
Aus Anwendersicht erwarte ich innerhalb einer Rastenstellung keine Änderung vom Positionswert. Aus Entwicklersicht definieren die Zustände /geschlossen-offen/ und /offen-geschlossen/ keine Rastenposition. Das lässt sich auch kodieren ("Hysterese").
Aus meiner Sicht hätte das nur beim Zustand /geschlossen-geschlossen/
passieren dürfen.
Jede Pegeländerung (sei es durch Prellen oder einen Störimpuls) an einem der beiden Eingänge muss eine Änderung des Zählerstandes bewirken. Also alles im grünen Bereich, du musst nur noch ein paar Minuten länger drüber nachdenken und dabei im Kopf behalten, dass die Software die blauen Linien nicht kennt, sie sieht nur die Pegel auf den beiden Spuren. Und da musst du einfach mal weiter reinzoomen, dann wird dir schnell klar, dass das Verhalten genau so sein muss.
Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die
Position sobald beide Kontakte geöffnet sind - das ist korrekt. Beim
anschließenden Schließen des ersten Kontakts (Störung) springt die
Position wieder zurück
Dann zeichne diese fragliche Stelle und eine Vergleichsstelle mal deutlich in das Bild ein.
Die rote (step=1) und grüne Linie (step=4) zeigen zum Vergleich die
Position bei anderen Step-Werten.
Offenbar kann man mit "step" die Art der Auswertung beeinflussen:
1 Zählerschritt pro komplettem Qadratursignaldurchlauf (00, 01, 11, 10),
2 Zählerschritte pro Signaldurchlauf und
4 Zählerschritte pro Signaldurchlauf.
Bei der Version mit 2 Zählerschritten wird eben nur auf die Flankenwechsel der oberen Spur reagiert. Aber: der Zählerstand (an der jeweiligen Raste) sieht bei jeder der vier Kurven nachvollziehbar und gut aus.
Die Elektronik weiß rein garnichts von irgendwelchen Rastpunkten.
Du siehst doch in deinem Zeitdiagramm, dass die Zeiten zwischen den Schleiferkratzereien (oder worin auch immer diese Störungen ihre Ursache haben), viel kürzer sind, als die Änderungen auf Grund der Kodierung der Geberscheibe. Da ist also schon viel Platz für Filterung.
Dann zeichne diese fragliche Stelle und eine Vergleichsstelle mal
deutlich in das Bild ein.
Siehe Bild im Anhang. Die Linie in Magenta zeigt die fragliche Stelle und die Linie in Türkis zeigt die aus Anwendersicht relevante Mitte zwischen zwei Rasten. Der Dekoder liefert an der fraglichen Stelle die Position von Raste 2, obwohl diese nicht vorliegt.
Offenbar kann man mit "step" die Art der Auswertung beeinflussen:
1 Zählerschritt pro komplettem Qadratursignaldurchlauf (00, 01, 11,
10),
2 Zählerschritte pro Signaldurchlauf und
4 Zählerschritte pro Signaldurchlauf.
In meinem Fall sieht der Anwender zwei Zählerschritte pro Signaldurchlauf. Die anderen beiden gibt es nur für den Entwickler.
Peters Dekoder-Software liefert bei realen Kontakten grundsätzlich ein Springen zwischen zwei Zuständen. Wenn sich der Dekoder (bei step=2) so wie von mir erwartet verhalten würde, dann wäre das Ergebnis auch bei realen Kontakten einwandfrei.
Der step-Parameter in encode_read() macht für mich keinen Sinn, da er ein Springen der Position nicht verhindert und eine anschließende Korrektur sogar unmöglich macht.
Da muss nichts korrigiert werden. Die Auswertung zeigt das, was physikalisch da ist. Wenn der Encoder prellt, dann prellt er. Die Auswertung zählt trotzdem richtig.
Wenn du das Signal glätten oder filtern willst, mach es hinter der Auswertelogik.
Der Ausgangspunkt für folgendes ist ein losgelassener Drehgeber. Der Geber befindet sich also auf einem Rastpunkt.
Was in Ordnung ist:
Wenn ich nach rechts drehe, dann gibt die Decoder-Software nicht in Mitte zwischen zwei Rastpunkten einen Impuls, sondern erst wenn etwas weiter gedreht wird.
Was fraglich ist:
Wenn ich nach links drehe, dann gibt die Decoder-Software nicht in Mitte zwischen zwei Rastpunkten einen Impuls, sondern bevor die die Mitte überschritten wird.
Was ich erwartet hätte:
Wenn ich nach links drehe, dann gibt die Decoder-Software nicht in Mitte zwischen zwei Rastpunkten einen Impuls, sondern erst wenn etwas weiter gedreht wird. -> Analog zur Rechtsdrehung. Ich finde das logisch und ein Prellen gibt es so auch nicht.
Was fraglich ist:
Wenn ich nach links drehe, dann gibt die Decoder-Software nicht in
Mitte zwischen zwei Rastpunkten einen Impuls, sondern bevor die die
Mitte überschritten wird.
Daran ist doch nichts fraglich. Die Rastpunkte stellen eine eindeutige Position dar. Was dazwischen passiert ist mehr oder weniger unspezifiziert.
Was ich erwartet hätte:
Wenn ich nach links drehe, dann gibt die Decoder-Software nicht in
Mitte zwischen zwei Rastpunkten einen Impuls, sondern erst wenn etwas
weiter gedreht wird.
Hast du vielleicht eine falsche Erwartungshaltung?
Dein Encoder mit Rastpunkten hat an den Rastposition einen eindeutigen Zustand und die Auswerteroutine von Peter dann einen eindeutigen Wert.
Ob der Wert während der Drehbewegung zwischen den Rastpunkten durch Prellen hin- und herspringt ist doch völlig egal wenn in der Ruhestellung dann der Wert immer eindeutig ist.
Die Routine von Peter macht das.
Ob der Wert während der Drehbewegung zwischen den Rastpunkten durch
Prellen hin- und herspringt ist doch völlig egal wenn in der
Ruhestellung dann der Wert immer eindeutig ist.
Wenn während des Vorwärtsdrehens vom Mausrad der Text vor und zurück springt, dann stört mich das extrem. Bei anderer Auswertung würde das nicht passieren.
Wenn während des Vorwärtsdrehens vom Mausrad der Text vor und zurück
springt, dann stört mich das extrem.
Zu Recht.
Bei anderer Auswertung würde das
nicht passieren.
Nö. Wenn dein Drehgeber bzw. Mausrad nicht total kaputt ist, passiert das nicht. Das Prellen eines Kanals führt nicht direkt und automatisch zum Springen des Textes. Denn man muss zwischen der direkten Dekodierung des Drehgebers und dessen Nutzung des Signals unterscheiden. Und gerade wenn man einen Dregeber mit x2 oder x4 Auflösung / Rastpunkten nutzt, passiert das an sich nicht, denn das Prellen wird in der höheren Auflösung "geschluckt" bzw. gefiltert. Klingt komisch, ist aber so.
Wenn während des Vorwärtsdrehens vom Mausrad der Text vor und zurück
springt, dann stört mich das extrem. Bei anderer Auswertung würde das
nicht passieren.
Ein Prellen der Kontakte bewirkt erstmal nur eine Änderung von enc_delta innerhalb der ISR. Und auch nur wenn die ISR oft genug aufgerufen wird.
Erst wenn die main dann encode_read aufruft wird der Wert von enc_delta in val übernommen. Für eine Anzeige reicht es völlig dies 5 bis 10 mal pro Sekunde zu tun. Und dann springt da üblicherweise auch nix.
Been there - done that. Mehrfach...
Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht
sich die Position sobald beide Kontakte geöffnet sind - das
ist korrekt. Beim anschließenden Schließen des ersten
Kontakts (Störung) springt die Position wieder zurück - das
ist unerwartet. Aus meiner Sicht hätte das nur beim Zustand
/geschlossen-geschlossen/ passieren dürfen.
Berechtigter Einwand.
Der Kanal, der sich als erstes ändert, definiert die
Richtung (delta:=+1 bzw. delta:=-1); der andere Kanal
addiert das delta zum Zählerstand und setzt delta:=0.
Aus Anwendersicht erwarte ich innerhalb einer
Rastenstellung keine Änderung vom Positionswert.
Aus Entwicklersicht definieren die Zustände
/geschlossen-offen/ und /offen-geschlossen/
keine Rastenposition. Das lässt sich auch
kodieren ("Hysterese").
„Eine neue [wissenschaftliche] Wahrheit pflegt sich
nicht in der Weise durchzusetzen, daß ihre Gegner
überzeugt werden und sich als belehrt erklären,
sondern vielmehr dadurch, daß die Gegner allmählich
aussterben und daß die heranwachsende Generation von
vornherein mit der Wahrheit vertraut gemacht ist. “
Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die
Position sobald beide Kontakte geöffnet sind - das ist korrekt. Beim
anschließenden Schließen des ersten Kontakts (Störung) springt die
Position wieder zurück - das ist unerwartet.
Peter hat sein Augenmerk darauf gerichtet, dass die Werte jeweils im
eingerasteten Zustand korrekt sind. Das Zappeln zwischen zwei Rastungen
lag offensichtlich nicht in seinem Fokus. Bei einschrittigen Encodern
lässt sich das ohnehin nicht vermeiden, für zwei- und vierschrittige
Encoder hingegen schon, wie du richtig erkannt hast:
Der Kanal, der sich als erstes ändert, definiert die
Richtung (delta:=+1 bzw. delta:=-1);
Sehe ich nicht so, egal was sich ändert, jede Änderung
hat eine Richtungsinformation. Die neuen zwei Bit
werden verglichen mit den vorherigen zwei Bit,
daran erkennt man die Richtung.
00 10 11 01 00 10 11 und so weiter
00 01 11 10 00 01 11 und so weiter,
ist entgegengesetzte Drehrichtung
Peter hat sein Augenmerk darauf gerichtet, dass die Werte jeweils im
eingerasteten Zustand korrekt sind. Das Zappeln zwischen zwei Rastungen
lag offensichtlich nicht in seinem Fokus. Bei einschrittigen Encodern
lässt sich das ohnehin nicht vermeiden,
Doch, indem man die Rastpunkte mechanisch zwischen die Codewechsel legt. Auch wenn das einige reale Drehgeber NICHT machen, warum auch immer.
Peter hat sein Augenmerk darauf gerichtet, dass die Werte jeweils im
eingerasteten Zustand korrekt sind. Das Zappeln zwischen zwei Rastungen
lag offensichtlich nicht in seinem Fokus. Bei einschrittigen Encodern
lässt sich das ohnehin nicht vermeiden,
Doch, indem man die Rastpunkte mechanisch zwischen die Codewechsel legt.
Damit verlagert man das Gezappel in einen Bereich, wo es weniger stört,
es ist aber immer noch vorhanden (s. rote Linie im ersten Screenshot des
TE). Der TE möchte es aber auch an diesen Stellen eliminieren. Das geht
softwaremäßig nur dann, wenn zwischen zwei Rastpunkten mindestens ein
weiterer Zustand liegt, was bei einschrittigen Encodern eben nicht der
Fall ist.
Die Bewegung des Drehgebers landet irgendwann in einem Zähler.
Den Wert dieses Zählers liest man (am besten direkt nachdem dieser neu gesetzt wurde) aus und führt dann folgendens aus:
Das ist ideal für die Abtastung im höchster Auflösung. Oder einem
Umschalter auf dem Rastpunkt. Da zappelt dann nichts mehr.
Das ist die berühmte Umkehr-Hysterese. Genau die hatte ich auch in meinem interruptgetriebenen Assembler-Code implementiert. Die ich hier zwar mal gepostet hatte, die ich aber dank der lausigen Suche einfach nicht wiederfinden kann, deswegen muss ich den Link schuldig bleiben.
Was man wissen muss: Dir geht ein Impuls verloren, wenn man rückwärts
dreht (nur bei der höchsten Auslösung). Der wird beim vorwärtsdrehen
wieder aufgeholt.
Ganz genau das ist der Nachteil dieser Umkehr-Hysterese. Jede Fehlauslösung auf einem Kanal (egal ob durch ESD oder Kontaktprellen) sorgt für einen Schritt in die falsche Richtung. Muss sie auch, das liegt in der Natur der Sache, denn es könnte ja tatsächlich ein Richtigungsänderung erfolgt sein, die Software kann das erst mal nicht entscheiden. Sie kann das erst abschließend entscheiden, wenn sich auch auf dem anderen Kanal was bewegt hat. Dann muß man halt ggf. die vorherige Fehlinterpretation als Richtungswechsel kompensieren, indem man zwei Schritte in der korrekten Richtung ausführt.
Das Problem ist nun: für eine Anwendung, die wirklich jeden Schritt nutzen will, führt das eben für jedes Prellen und jeden ESD-Störpuls zu der Folge vorwärts-ein Schritt zurück-zwei Schritte vor.
Es gibt (scheinbar) zwei Lösungen zur Abhilfe:
In der Anwendung nur die halbe Zählerauflösung verwenden. Dann wackelt nix mehr. Nachteil: die Auflösung wird halt halbiert.
Die Rückmeldung eines Umkehrschrittes an die Anwendung verzögern, bis er "committed" ist, also sich auch auf dem anderen Kanal was bewegt hat. Leider führt aber auch das genauso dazu, dass effektiv nur die halbe Auflösung nutzbar ist. Der Schritt ist zwar physisch schon passiert und auch registriert, kommt aber bei der Anwendung noch nicht an.
Effektiv sind also die beiden Lösungen von der Implementierung her durchaus verschieden, aber im Endergebnis equivalent.
Beide Ansätze ergeben bei einer kontinuierlichen Erhöhung oder Verringerung aus Anwendungssicht jedenfalls ein sehr viel gefälligeres Bild, aber halbieren halt effektiv auch die Auflösung.
Sprich: eine "perfekte" Lösung für volle Auflösung ist nur möglich, wenn Prellen und ESD schon vorher bekämpft werden (oder erst garnicht vorhanden sind). Bei einer nötigen Bekämpfung hat diese dann aber wiederum andere Nachteile durch die dann zwangsäufig zu verwendenen Zeitkonstanten.
Das ist ideal für die Abtastung im höchster Auflösung. Oder einem
Umschalter auf dem Rastpunkt. Da zappelt dann nichts mehr.
Was man wissen muss: Dir geht ein Impuls verloren, wenn man rückwärts
dreht (nur bei der höchsten Auslösung). Der wird beim vorwärtsdrehen
wieder aufgeholt.
Ganz genau das ist der Nachteil dieser Umkehr-Hysterese. Jede
Fehlauslösung auf einem Kanal (egal ob durch ESD oder Kontaktprellen)
sorgt für einen Schritt in die falsche Richtung...
In der höchsten Auflösung schon. Wenn man rückwärts dreht, ist der Wert um eins zu hoch. Beim vorwärts drehen, ist alles wieder gut. Das ist bei Handdrehgebern meist unproblematisch. Dafür flattert da nichts.
Das passiert aber nur in der höchsten Auflösung, und die ist hier nicht gefordert.
Bei der halben Auflösung, wie es hier gewünscht ist, funktioniert es ohne Probleme. Und es geht auch nichts verloren. Und flattern tut es auch nicht.
Warum ist das Verhalten korrekt? (Oder verwende ich den Dekoder falsch?)
Das Verhalten habe ich auch festgestellt:
Ich versuche es mal grafisch darzustellen. Die halbe Sequenz:
1
Vorwärts:
2
3
Rastung | | | | |
4
A ---|___|___|---|---|___|___|---|---|
5
B ---|---|___|___|---|---|___|___|---|
6
Peter | | | |
7
Uwe | | | |
8
9
Das ist identisch und sieht gut aus. Jetzt rückwärts:
10
11
Rastung | | | | |
12
B ---|---|___|___|---|---|___|___|---|
13
A ---|___|___|---|---|___|___|---|---|
14
Peter | | | |
15
Uwe | | | |
Hier sieht man, dass bei Peter der Schritt schon beim ersten Impuls
gemacht wird. Idealerweise sollte es beim zweiten Impuls erfolgen. Damit
reduziert man die Wahrscheinlichkeit beim Drücken des Drehgebers weiter
zu drehen.
Ist ein Ausschnitt aus dem Link, und da ist auch die Lösung enthalten:
Die Bewegung des Drehgebers landet irgendwann in einem Zähler.
Den Wert dieses Zählers liest man (am besten direkt nachdem dieser neu
gesetzt wurde) aus und führt dann folgendens aus:
if (zähler != germerkter_wert) {
ausgabe = (zähler + gemerkter_wert)>>1;
gemerkter_wert = zähler;
}
("Filter" sind eigentlich ein neues Thema.)
Ich habe den Filter mal getestet:
Der Effekt ist gut, aber leider hinkt die Position beim Richtungswechsel hinterher - bei mir zumindest. Es gibt quasi einen Leerschritt, was in Regel nicht akzeptabel ist.
Der Effekt ist gut, aber leider hinkt die Position beim Richtungswechsel
hinterher
Das ist der Sinn dieses Filters: es soll eben gerade nicht auf jeden einzelnen "Umkehrschritt" reagiert werden. Und dabei ist es der Software dann egal, ob dieser Schritt vom lausigen Geber oder von einer Bedienereingabe kommt. Sie kann das ja auch gar nicht unterscheiden.
Es gibt quasi einen Leerschritt, was in Regel nicht akzeptabel ist.
Gerade bei Geräten mit Drehgeberbedienung ist die absolute Position des Eingsberades völlig irrelevant. Das geht soweit, dass man sogar mit Dynamik arbeiten und bei schnell(er)em Drehen mehr als 1 Schritt pro Impuls machen kann. Dieses Verhalten ist z.B. auch von Computermäusen bekannt.
Gerade bei Geräten mit Drehgeberbedienung ist die absolute Position des
Eingsberades völlig irrelevant. Das geht soweit, dass man sogar mit
Dynamik arbeiten und bei schnell(er)em Drehen mehr als 1 Schritt pro
Impuls machen kann. Dieses Verhalten ist z.B. auch von Computermäusen
bekannt.
Bei schnellem Drehen sehe ich das auch so. Bei langsamen Drehen sehe ich das anders. Ich möchte ohne auf ein Feedback warten zu müssen gezielt/blind eine Schrittzahl eingeben können.
Das Problem ist nun: für eine Anwendung, die wirklich jeden Schritt
nutzen will, führt das eben für jedes Prellen und jeden ESD-Störpuls zu
der Folge vorwärts-ein Schritt zurück-zwei Schritte vor.
Die Anwendung will das hier aber nicht. Hier geht es um einen Geber mit vier Zuständen, bei dem es alle zwei Zustandsänderungen eine Positionsänderung gibt.
Egal, ich beuge mich mal der Mehrheit. Ich gebe auf. Danke.
Nicht aufgeben.
Versuche das mal, und berichte:
Beitrag "Re: Drehgeber/Encoder 1-, 2- oder 4-schrittig"
Das ist ideal für die Abtastung im höchster Auflösung. Oder einem
Umschalter auf dem Rastpunkt. Da zappelt dann nichts mehr.
Entscheident ist die Funktion "encode".
Bitte erst ausprobieren, dann über das Ergenis berichten.
Bin gespannt...
Im Anhang das Ergebnis: Es zeigt die Impulse von sechs Dekodern bei echten Messwerten.
Messwerte:
Die Messwerte stammen von einer zwei Jahre alten Maus. Der Drehgeber liefert ein schlechtes Signal und die Maus sprang bereits im ersten Jahr. Zum Teil liegt das an der Firmware, da diese Geschwindigkeiten von unter 250µs/Schritt zulässt, obwohl Werte unter 2000 µs/Schritt praktisch nicht erreichbar sind.
Man sieht fünf Zeilen mit Messwerten. Bei den ersten beiden Zeilen wurde das Mausrad langsam bis normal gedreht. Bei der dritten Zeile sehr schnell. Bei den letzten beiden Zeilen wurde die Handfläche "mit Anlauf" schnellstmöglich über das Rad bewegt.
Für mich wichtig beim Mausrad ist:
Die Drehrichtung sollte immer stimmen.
Beim langsamen Drehen sollte die Position immer stimmen.
Bei langsamen Drehen sehe ich
das anders. Ich möchte ohne auf ein Feedback warten zu müssen
gezielt/blind eine Schrittzahl eingeben können.
Das ist bei Geräten, bei denen man z.B. ein Menü mit einem Drehgeber bedient, wichtig. Da möchte man präzise einen Schritt vor oder zurückgehen können, und diese Schritte müssen mit den Rasten zu tun haben.
Bitte erst ausprobieren, dann über das Ergenis berichten.
Bin gespannt...
..ganz vergessen.
Meine Messdaten reichen aus um 645 solcher Screenshots zu erstellen. Normalerweise werte ich Daten automatisch aus. Hier habe ich das mit dem Auge gemacht. Auf den ersten Blick erreicht er den vierten Platz. Wenn man die Einfachheit berücksichtigt, dann sogar Platz 1.
... Auf den ersten Blick erreicht er den vierten Platz. Wenn
man die Einfachheit berücksichtigt, dann sogar Platz 1.
Das ist doch garnicht so schlecht.
Diese Auswertung im Grenzbereich, finde ich sehr interessant.
Wir sind uns auch einig, dass man den Drehgeber eindeutig als "Defect" bezeichnen darf.
Mein Algorithmus zeigt die wenigsten Fehlimpulse, wenn ich das richtig sehe. Problematisch, für deine Anforderung, sind die gelegendlich auftretenden rückwärts Schritte.
Folgendes könnte man versuchen:
Man lässt einen Richtungswechsel erst nach eine Pause von 50ms zu.
Dann sollte es bei schneller Betätigung keine Richtungswechsel geben. Das dabei immernoch zu viele Impulse erzeugt werden, ist bekannt.
Ich erwarte auch keine Probleme beim langsamen Drehen.
Wir sind uns auch einig, dass man den Drehgeber eindeutig als "Defect"
bezeichnen darf.
Da bin ich mir nicht sicher. Die "Menge" der Störungen hängt extrem von der Drehgeschwindigkeit ab. Bei normaler Geschwindigkeit ist alles Ok. Vielleicht haben mehr Geber ein solches Signal als man glaubt. Außerdem wäre zumindest dieser Geber auch bei Extremgeschwindigkeit noch verwendbar, wenn der Dekoder robuster wäre.
(Beitrag "Re: Handbetriebenen Drehgeber ohne Timer auswerten")
Mein Algorithmus zeigt die wenigsten Fehlimpulse, wenn ich das richtig
sehe. Problematisch, für deine Anforderung, sind die gelegendlich
auftretenden rückwärts Schritte.
Nee, es ist der erste Dekoder ("Spezialdekoder") mit den wenigsten Fehlimpulsen.
Ein Tiefpass an den Eingängen könnte sich das sehr hilfreich erweisen.
Ein spezieller Tiefpass wäre besser. Das liegt daran, dass der offene Kontaktzustand immer korrekt vom Geber zurückgegeben wird und nur der geschlossene Kontakt "manchmal" fehlerhaft als offen zurückgegeben wird.
Ein normaler Filter würde die Kontaktzeiten zu sehr verfälschen.
dann muss Daniel etwas Geld in die Hand nehmen und einen optischen oder magnetischen Drehencoder verwenden, der nicht prellt. Dann hat er seine hohen Anforderungen erfüllt. Übrigens ist der Verweis auf eine Computermaus hier nicht passend, diese verwenden optischen Abtastung vom Drehrad.
Irrtum. Dieses Signal kommt von einer Cherry-Maus.
Auch viele andere Maushersteller verwende für das Scrollrad einen mechanischen Encoder.
Tatsächlich gab es sogar damals(tm) Kugelmäuse, deren Kugelbewegung ebenfalls mechanisch abgetastet wurde.
Das war beispielsweise bei der Microsoft InPort-Maus der Fall, in der Maus selbst war keinerlei Elektronik untergebracht, alle Taster/Encoder wurden an eine PC-Steckkarte geführt und erst dort ausgewertet.
Ich habe bei Cherry - diesmal vor dem Kauf - für eine andere
teuerere
Maus nachgefragt, ob die auch mechanisch abgenommen wird. -> "Ja".
Hab' 'ne einfache Cherry JF-T03, vierter oder fünfter Links-Switch, zweiter Rechts-Switch, Mausrad-Drehgeber immer noch Original. Und das (mechanische) Mausrad hat sicherlich mittlerweile die Mille Miglia zurück gelegt.
Nee, es ist der erste Dekoder ("Spezialdekoder") mit den wenigsten
Fehlimpulsen.
Mit Fehlimpulsen sind die vorwärts Schritte gemeint, die nicht wirklich
da sind.
Was die Drehrichtung angeht, hat nur der erste Dekoder keinen einzigen Fehlimpuls. Wenn man nicht zu schnell dreht, dann gibt es außerdem dort auch keine Positionsfehler. Nur unten rechts fehlen ein paar Impulse, die Richtung wurde (verständlicherweise) nicht erkannt.
Und was ist mit dem filtern der Rückwärtsschritte, wenn man einen
Richtungswechsel erst nach eine Pause von 50ms zulässt?
Ein Filter für den Richtungswechsel ist nicht trivial. Bei einfacher Umsetzung sieht man vor allem einen unangenehmen Nebeneffekt. Wenn beispielsweise der erste Impuls nach einer Pause falsch erkannt wird, dann sind alle weiteren Impulse falsch. Unter dem Strich macht es alles noch schlimmer. Das war zumindest meine Erfahrung.
Es geht hier um den Geber in einer Maus. Normalerweise wirft man die Maus weg, wenn der Geber nicht mehr anständig funktioniert. Den Geber auszutauschen wäre möglich, wenn man anspruchslos ist (Lautstärke, Taktilität) oder kein Problem mit Trial-Error-Käufen hat - trifft auf mich nicht zu. Aus reiner Spielerei würde ich vielleicht zwischen Geber und Hauptplatine einen µC als "Hörgerät" einbauen. Einen anderen Gebertyp einzubauen ginge mir viel zu weit. Geht das überhaupt?
Der blaue Bereich ist kein prellen, sondern Kontakt Fehler durch Verschmutzung. Hier sollten beide Schleifer einen Kontakt haben. Es sollte idealerweise nichts passieren, da es vorher einen sauberen Kontakt gab. Offene Kontakte prellen nicht.
Anzahl der Fehllesungen bei deinem Favoriten: 17
Anzahl der Fehllesungen bei meinem Algo: 4
Muss jeder für sich selbst entscheiden, wer zuverlässiger arbeitet.
Ich muss leider sagen, dass dieser Drehgeber so stark verschmutz ist, dass man ihn nicht mehr gebrauchen kann. Es gleicht eher einem Zufallsgenerator.
Der blaue Bereich ist kein prellen, sondern Kontakt Fehler durch
Verschmutzung. Hier sollten beide Schleifer einen Kontakt haben.
Nö. Die allermeisten Zustände wurden korrekt erkannt. Der blaue Bereich ist keine Störung, es sind lediglich Störungen enthalten. Das kann man als Mensch doch klar erkennen. Das meine ich wirklich so.
Nicht vergessen, bei den letzten beiden Meßdatenzeilen wurde die Hand extrem schnell über das Rad bewegt. Das ist absolut praxisfern. Die mittlere Datenzeile zeigt sehr schnelle aber vorkommende Radgeschwindigeiten.
Geschwindigkeiten wie in der mittleren Zeile kommen schon vor. Dein Dekoder würde das nur erlauben (ohne Impulse zu verschlucken), wenn die Routine häufiger aufgerufen werden würde. Dann würde aber die Fehlerqoute steigen.
Kein Algo kann ein Prellen an beiden Kontakten sinnvoll
auswerten.
Naja, das tritt nur bei so hohen Drehzahlen auf, bei denen die exakte Impulszahl nicht mehr wichtig ist und die grobe Bestimmung der Impulse klappt doch wie man am Screenshot sieht ziemlich gut.
das es sich um eine Computermaus direkt handelt hättest du aber gleich von Anfang an sagen können. Dann hätte das Rätselraten nicht sein müssen. Ganz ehrlich. Weitermachen...
Bei normaler Geschwindigkeit ist alles Ok.
Vielleicht haben mehr Geber ein solches Signal als man glaubt. Außerdem
wäre zumindest dieser Geber auch bei Extremgeschwindigkeit noch
verwendbar, wenn der Dekoder robuster wäre.
(Beitrag "Re: Handbetriebenen Drehgeber ohne Timer auswerten")
Ich habe hier nur mit halbem Ohr mitgelesen. Weiter unten zu Deinem Link ist ja auch die RC-gefilterte Kurve mit aktiver Hysterese zu sehen.
Wenn Du nicht scheust, zwei Widerstände und zwei Kondensatoren zu ergänzen, könnte ich Dir das zugehörige Programm schicken - für Arduino oder AVR-Studio.
Der Einbau ist kein Problem, die zusätzlichen Bauteile verändern aber das Kontaktsignal. Für andere Algorithmen ist es damit nicht mehr verwendbar, was aber für einen objektiven Vergleich nötig wäre. Ein subjektiver Vergleich geht praktisch auch nicht, da man über einen sehr langen Zeitraum drehen müsste, um Verbesserungen gegenüber dem "Spezialdekoder" (https://www.mikrocontroller.net/attachment/688014/Gegenueberstellung.png) zuverlässig wahrnehmen zu können.
Das passiert aber nur in der höchsten Auflösung, und die ist hier nicht
gefordert.
Ja.
Bei der halben Auflösung, wie es hier gewünscht ist, funktioniert es
ohne Probleme. Und es geht auch nichts verloren. Und flattern tut es
auch nicht.
Erst ausprobieren, und dann schreiben.
Die Tatsache, das ich eine entsprechende Lösung schon vor Jahren hier gepostet hatte, sollte klarstellen, dass ich das bereits umfassend ausprobiert habe.
Spätestens aber die beiden Lösungsvorschläge in meinem Posting sollten das auch ohne umfassende Geschichtskenntnisse klargestellt haben...
Das ist bei Geräten, bei denen man z.B. ein Menü mit einem Drehgeber
bedient, wichtig. Da möchte man präzise einen Schritt vor oder
zurückgehen können, und diese Schritte müssen mit den Rasten zu tun
haben.
Tja, das Problem ist halt: die Software weiss nichts von irgendwelchen (rein mechanischen) Rasten und hat auch keinerlei Möglichkeit, zu ermitteln, ob die Mechanik jetzt gerade eingerastet ist oder nicht.
Alles, was man der Software mitteilen kann, ist die gewünschte "Untersetzung" ihrer elektrischen Realität. Also effektiv: wieviele LSB des Zählerstands sie wegwerfen darf, bevor sie das Ergebnis der Nutzung zuführt.
Die Tatsache, das ich eine entsprechende Lösung schon vor Jahren hier
gepostet hatte, sollte klarstellen, dass ich das bereits umfassend
ausprobiert habe.
War kein Vorwurf. Wollte nur theoretische Argumente vermeiden, die nichts mit der Praxis zu tun haben.
Das eine Abtastung bei der höchsten Auflösung eigentlich keinen Sinn macht, ist mir jetzt auch bewusst geworden. Also besser nicht. Da es auch einen Drehgeber benötigt, der eine gute Phasengenauigkeit bereitstellt. Und dann doch lieber was Optisches.
Das Ergebnis interessiert mich sehr. Ist irgendetwas schlecht an meinem Algo ? Für konstruktive Argumente bin ich sehr offen.
Das Ergebnis interessiert mich sehr. Ist irgendetwas schlecht an meinem
Algo ? Für konstruktive Argumente bin ich sehr offen.
Der Dekoder erwartet eine exakte Zustandsfolge für einen Schrittimpuls. Jede Störung in Abfolge führt dazu, dass kein Schrittimpuls erzeugt wird. Auf diese Weise treten Schrittimpulse mit falscher Richtung seltener auf, dafür fehlen Schrittimpulse für tatsächlich vorgekommene Schritte. Nur wenn das nicht vermeidbar wäre, dann wäre der Dekoder sehr gut. (Für die spezielle Anforderung "besser keine als falsche Impulse" ist er sehr gut.)
Der Dekoder erwartet eine exakte Zustandsfolge für einen Schrittimpuls.
Jede Störung in Abfolge führt dazu, dass kein Schrittimpuls erzeugt
wird.
Das ist richtig. Eine Störung auf einer Leitung wird dadurch gefiltert. Folgt dann ein tatsächlicher Schritt, ist es wieder eine komplette Sequenz. Tatsächliche Schritte gehen dann nicht verloren.
Problematisch ist eine Störung auf der zweiten Leitung, wenn die erste noch im Störbereich ist. Das erzeugt einen tatsächlichen Schritt, der nicht da ist. Dann haben wir zu viele Impulse.
Wenn beide Leitungen gleichzeitig umschalten, geht tatsächlich ein Impuls verloren. Bei der Annahme, dass sich die Richtung nicht geändert hat, könnte man den fehlenden Impuls rekonstruieren. Ich vermute, dass es der Schritt ist, den du vermisst. Es ist aber auch ein Indikator, dass man zu schnell gedreht hat. Und es erklärt das Verhalten des "Spezialdecoders".
Der Grund ist ein anderer (sorry): Durch einen Programmfehler lieferte der "Dekoder von Peter Dannenegger - modifiziert" (siehe https://www.mikrocontroller.net/attachment/688014/Gegenueberstellung.png) wenn die Richtung widersprüchlich ist, einen Rückwärts-Impuls. Deswegen sah es für mich so aus, als ob dein Dekoder zu viele Impulse verschluckt. Tatsächlich liefern, solange beim Übergang von Raste zu Raste nur auf einem Kontakt Störungen auftreten, beide identische Werte. Falls aber beim Übergang mindestens einmalig eine gleichzeitige Änderung auf beiden Kontakten stattfand, dann gibt es Unterschiede. Es gibt drei Möglichkeiten:
immer einen Impuls ausgeben
Das macht (bzw. hätte er machen sollen) der "Dekoder von Peter Dannenegger - modifiziert".
nur dann, wenn das "nicht zum Schluss" passiert
Das macht dein Dekoder
niemals einen Impuls ausgeben
Diese Variante habe ich getestet und die liefert noch seltener eine falsche Richtung :-), dafür gehen noch mehr Impulse verloren. :-(
Drehgeber_step2.png
(1,8 KB)
