Beim Testen des Drehgeber-Dekoders von Peter Dannegger (https://www.mikrocontroller.net/articles/Drehgeber#Solide_L%C3%B6sung:_Beispielcode_in_C) ist mir ein unerwartetes Verhalten aufgefallen. 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?)
Angehängte Dateien:
-
Drehgeber_step2.png
1,8 KB
:
Bearbeitet durch User
Daniel V. schrieb: > 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.
Ob S. schrieb: > 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.
Ob S. schrieb: > 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.
Rainer W. schrieb: > Ob S. schrieb: >> 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.
Daniel V. schrieb: > Das Problem: Beim Übergang von Raste 2 nach Raste 3 erhöht sich die > Position sobald beide Kontakte geöffnet sind - das ist korrekt. Die rote sum Linie sieht sehr gut aus. > Beim > anschließenden Schließen des ersten Kontakts (Störung) springt die > Position wieder zurück - das ist unerwartet Unerwartet ? Natürlich muss die Position zurückspringen sonst würde sie beim erneuten öffnen des Kontakts schon um 2 weiter schalten. Die Rasten sind dort, wo es ungestört ist, damit die angezeigte Zahl nicht flattert.
Michael B. schrieb: > Die rote sum Linie sieht sehr gut aus. Das sehe ich auch so. Bei step=1 ist es wie von mir erwartet. Michael B. schrieb: > 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").
:
Bearbeitet durch User
Daniel V. schrieb: > 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. Michael B. schrieb: > Die rote sum Linie sieht sehr gut aus. Das ist das einzige, was hier zählt: es gibt keine "Verzähler" oder "Überseher" oder gar Sprünge.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Michael B. schrieb: >> Die rote sum Linie sieht sehr gut aus. > Das ist das einzige, was hier zählt: es gibt keine "Verzähler" oder > "Überseher" oder gar Sprünge. Die rote Linie zählt hier aus meiner Sicht nicht. Nach den Rasten ist doch für step 2 zu verwenden - also die blaue Linie.
Angehängte Dateien:
-
Drehgeber_step2.png
2,6 KB
Daniel V. schrieb: > 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. Daniel V. schrieb: > Die rote Linie zählt hier aus meiner Sicht nicht. Naja, dort wird halt die übliche 4-fach Auswertung verwendet: bei jeder Raste hat sich der Zählerwert geändert.
:
Bearbeitet durch Moderator
Ob S. schrieb: > 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.
Angehängte Dateien:
-
Detail.png
1,1 KB
Lothar M. schrieb: > 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. Lothar M. schrieb: > 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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.