Ich habe ein ganz seltsames Problem mit den Drehgebern in meinem Projekt. Erwartetes Verhalten eines Drehgebers beim Drehen ist ist ja Erzeugung 2 phasenversetzter Rechtecksignale. Dann hat man im Ruhezustand, also im gerasteten Zustand immer High (nehmen wir Pull-Up Konfig. an). Das heißt, der gerasteter Zustand muss immer stabil sein. Genau da ist mein Problem. Ich bekomme zwar erwartete Rechtecksignale. Schön und gut. Aber nach den "Clicks" bleibt ganz sporadisch der Zustand des einen oder anderen Pins auf "Low", da der innere Fühler wahrscheinlich noch kontaktiert. Ich habe das ganze im Logik-Analyser wie im Multimeter untersucht. Da sieht man ganz genau, dass man mit leichten Bewegungen den Zustand eines Pins innerhalb vom Raster(!) bleibend auf Low oder High ziehen kann. Man kontaktiert den Fühler mit kleinen Bewegungen innerhalb vom Raster quasi hin und her, dass es so bleibt. Siehe LA-Screenshot: Erst gibt's schöne Quadratursignal, dann springt der erste Pin irgendwann auf Low...Das passiert eben sporadisch. Das heißt, dieser Encoder ist im gerasteten Zustand einfach nicht stabil. Encoder sind diese Standardencoder:https://www.reichelt.de/drehimpulsegeber-24-impulse-24-rastungen-vertikal-stec12e08-p73923.html Habe mehrere davon aufm Board und alle leiden unter demselben Problem. Manche mehr, manche weniger. Sind die Encoder absoluter Müll oder habe ich einen Verständnisfehler? Oder was mache ich falsch? Dankbar für jeden Tipp!
Angehängte Dateien:
-
encoder1.png
346 Bytes -
encoder2.png
120 KB
:
Bearbeitet durch User
> (Gray-Code Implementierung)
Low hin, High her. So wie ich es sehe hast du einen definierten Zustand.
Deine Drehgeber gehen von Zustand zu Zustand.
Im Datenblatt (von 1997), Seite 5 steht: > (The dent position will always be alignet with A-phase > but B-phase has no specification. Ich lese das so, dass das B-Signal irgendwo rumhängen kann wenn der Encoder eingerastet ist.
Bernd schrieb: > (Gray-Code Implementierung) > > Low hin, High her. So wie ich es sehe hast du einen definierten Zustand. > Deine Drehgeber gehen von Zustand zu Zustand. Und was nutzt das wenn der dann im gerasteten Zustand sporadisch um1 pendelt? Das doch je nach Anwendung sehr beschissen...
Es gibt 2 Sorten von Drehgebern. Die einen sind immer zwischen den Rastungen stabil und die anderen wechseln einen Anschluß genau auf der Rastung. Diese sind dann so zu schalten, daß das Zählen immer auf dem stabilen Anschluß erfolgt, d.h. der wackelnde Anschluß ist egal. Rastende Drehgeber benötigen ja immer 2 oder 4 Phasen für einen Zählschritt, also ist das einfach durch Umpolen möglich.
> Sind die Encoder absoluter Müll oder habe ich einen Verständnisfehler? > Oder was mache ich falsch? Abstastung im TimerIRQ oder bist du so dumm die Flanken auszuwerten? Es gibt kein Problem bei den Teilen ein stabiles Ausgangssignal zu erhalten wenn man richtig, also mit TimerIRQ, auswertet. Allerdings ist auch mir schon aufgefallen das der mit den Fingern gefuehlte Pegelwechsel nicht der tatsaechlich ausgegeben Rastung folgt. Es gibt also bei manchen Encodern einen Winkelversatz. Da hab ich mich auch schon gefragt was der Entwickler davon geraucht hat. Olaf
Olaf schrieb: > Allerdings ist auch mir schon aufgefallen das der mit den Fingern > gefuehlte Pegelwechsel nicht der tatsaechlich ausgegeben Rastung folgt. > Es gibt also bei manchen Encodern einen Winkelversatz. Rastpunkte mechanisch zu designen ist nicht so einfach, wie es klingt. Das ist einfach Toleranz.
Angehängte Dateien:
-
encoder.png
17 KB
Olaf schrieb: > Abstastung im TimerIRQ oder bist du so dumm die Flanken auszuwerten? Bisher habe ich im TimerIRQ von STM32 ausgewertet (Die haben ja Quadraturzähler) Das funktioniert eben nicht einwandfrei. Daher wollte ich jetzt eine Zustandsmaschine (Gray-Code) implementieren und komplett auf Polling gehen. Dieser Ansatz kann aber bei diesen Drehgebern nicht klappen, da eben am Ende nicht immer (1-1) oder (0-0) stehen muss. Stimmt's? Hier übrigens eine neuere Doku: https://cdn-reichelt.de/documents/datenblatt/B400/STEC12E.pdf Da ist auf der letzten Seite das Ausgangssignal beschrieben. Da Peter D. schrieb: > Es gibt 2 Sorten von Drehgebern. Die einen sind immer zwischen den > Rastungen stabil und die anderen wechseln einen Anschluß genau auf der > Rastung. Diese sind dann so zu schalten, daß das Zählen immer auf dem > stabilen Anschluß erfolgt, d.h. der wackelnde Anschluß ist egal. > Rastende Drehgeber benötigen ja immer 2 oder 4 Phasen für einen > Zählschritt, also ist das einfach durch Umpolen möglich. Das wusste ich so nicht. Dann fasse ich mal mein Verständnis zusammen: 1. A ist stabil, B ist instabil. 2. Im gerasteten Zustand, können die Pins(besonders B) da stehen, wo sie wollen. 3. Wenn ich drehe, gibt es ein Flankenwechsel auf B. (Ähnlich wie ein CLK Signal). 4. Ich muss einfach im Zeitpunkt dieses Flankenwechsels den Zustand von A auswerten, um die Drehrichtung zu ermitteln. 5. Danach wenn der Drehgeber wieder im nächsten Raster gerastet ist, gammelt der Pin B auf Low oder High. Frage: Wenn der Pin B im Rasterzustand undefiniert ist, kann er aber beim "im Raster hin und her wackeln" unerwünschte Flanken erzeugen und da werte ich wieder Bullshit aus. Stimmt's? Wie löse ich das denn?
:
Bearbeitet durch User
> Das wusste ich so nicht. Dann fasse ich mal mein Verständnis zusammen: > 1. A ist stabil, B ist instabil. Nein. Es kann jederzeit mal passieren das einer der beiden seinen Zustand aendert. Das ist vollkommen okay so, passiert auch beim drehen oft wenn der Schalter prellt. Allerdings eben nur bei einem der schalter, der andere ist stabil. Das mittelt dir dann dein TimerIRQ wieder raus. > 4. Ich muss einfach im Zeitpunkt dieses Flankenwechsels den Zustand von > A auswerten, um die Drehrichtung zu ermitteln. Nein, genau das nicht! Es gibt keinen definierten einmalig auftretenden Flankenwechsel. Das musst du verstehen! Olaf
Ich sehe grad, daß meine Encoderroutine dafür nicht geeignet ist. Es fehlt die Synchronisation beim Einschalten, so daß nur bei Flankenwechsel auf A gezählt wird. Ich hatte nur solche Encoder verwendet, wo beide Anschlüsse stabil sind.
Solocan Z. schrieb: > nach den "Clicks" bleibt ganz sporadisch der Zustand > des einen oder anderen Pins auf "Low" Bleibt der stabil auf Low? Dann ist die ursprüngliche Forderung ja erfüllt: > Das heißt, der gerasteter Zustand muss immer stabil sein. Solocan Z. schrieb: > Bisher habe ich im TimerIRQ von STM32 ausgewertet (Die haben ja > Quadraturzähler) Das funktioniert eben nicht einwandfrei. Warum nicht? diese Hardware ist doch genau für diese Signale ausgelegt... > Daher wollte ich jetzt eine Zustandsmaschine (Gray-Code) implementieren > und komplett auf Polling gehen. Dieser Ansatz kann aber bei diesen > Drehgebern nicht klappen, da eben am Ende nicht immer (1-1) oder (0-0) > stehen muss. > Stimmt's? Nein. Wegen der Qaudraturauswertung bekommst du ja 4 Schritte pro Rastung. Und manchmal macht der Drehgeber jetzt halt nur 3 Schritte und dann bei der nächsten Rastung eben irgendwann mal 5. > Genau da ist mein Problem. Warum? Was ist denn jetzt das eigentliche Problem? BTW: es ist eine schlechte Idee, direkt mit dem Geber einen Wert 1:1 zu ändern. Denn dann kann es sein, du triffst den gewünschten Wert einfacher, wenn du eine "Beschleunigung" mit ins Spiel bringst.
Lothar M. schrieb: > Nein. Wegen der Qaudraturauswertung bekommst du ja 4 Schritte pro > Rastung. Und manchmal macht der Drehgeber jetzt halt nur 3 Schritte und > dann bei der nächsten Rastung eben irgendwann mal 5. > >> Genau da ist mein Problem. > Warum? > Was ist denn jetzt das eigentliche Problem? > > BTW: es ist eine schlechte Idee, direkt mit dem Geber einen Wert 1:1 zu > ändern. Denn dann kann es sein, du triffst den gewünschten Wert > einfacher, wenn du eine "Beschleunigung" mit ins Spiel bringst. Genau da eben! Ich muss doch immer diese 4 Schritte bekommen, damit es funktioniert. Sonst kann ich nicht sagen: Ok, eine vollständige Drehung hat erfolgt! Ich glaube, ich habe vergessen, meinen Use-Case zu erläutern. Ich nehme diese Encoder nicht als Motordrehgeber (, wo er kontinuierlich dreht und egal ist, wo es beim Rasten steht.) sondern als Benutzerschnittstelle! Daher muss bei mir eben "1:1" ausgewertet sein. Sprich, ein Tick Uhrzeigersinn-> Wert hoch, ein Tick Gegenuhrzeigersinn->Wert runter. Das nicht sporadisch sondern IMMER. Wenn ich manchmal 3 und manchmal 5 Ticks habe, funktioniert es eben nicht, da ich nie eine einzige Rastung sauber ermitteln kann. (Bei der zweiten Rastung wird's von mir aus ausgeglichen aber das ist mir egal, weil der Anwender es ehe wieder runterdrehen möchte)
:
Bearbeitet durch User
Solocan Z. schrieb: > > Bisher habe ich im TimerIRQ von STM32 ausgewertet (Die haben ja > Quadraturzähler) Dieser Satz ergibt IMHO keinen Sinn. Entweder verwendest du einen Quadraturzähler oder du machst was im Interrupt. > Das funktioniert eben nicht einwandfrei. Daher wollte > ich jetzt eine Zustandsmaschine (Gray-Code) implementieren und komplett > auf Polling gehen. Dieser Ansatz kann aber bei diesen Drehgebern nicht > klappen, da eben am Ende nicht immer (1-1) oder (0-0) stehen muss. > Stimmt's? Nein, stimmt nicht. Eine korrekt implementierte Zustandsmaschine wertet alle 4 möglichen Zustände des Encoders aus. Nehmen wir mal das Impulsdiagramm von dir. Dann gibt es 4 Zustände:
1 | A B Zustand |
2 | ------------- |
3 | H H Z1 |
4 | L H Z2 |
5 | L L Z3 |
6 | H L Z4 |
Beim Drehen des Encoders werden diese 4 Zustände zyklisch durchlaufen. Entweder vorwärts Z1 -> Z2 -> Z3 -> Z4 -> Z1 ... oder rückwärts. In keinem Fall werden Zustände übersprungen. Nach Z1 kann nur entweder Z2 oder Z4 folgen, niemals Z3. Wenn du jetzt anschaust, wo die Rastpunkte dieses Encoders liegen, dann ist das der Übergang Z4 -> Z1 (bzw. Z1 -> Z4). Durch Fertigungstoleranzen kann der Rastpunkt mal kurz davor oder kurz danach liegen. Oder man kann durch Wackeln an der Achse diesen Übergang beliebig überqueren. Die anderen drei Zustandsübergänge sind aber stabil. Da der Encoder mechanisch (per Rastung) ohnehin nur 1/4 der elektrischen Auflösung hat, brauchst du also nur einen dieser anderen 3 Zustandsübergänge zum Herauf- bzw. Herunterzählen des Geber-Wertes zu verwenden. Zweckmäßigerweise nimmst du den Übergang in der Mitte (Z2 <-> Z3). Der Code im Artikel Drehgeber kann das übrigens alles. Mit den dort gewählten Worten ist dein Encoder ein "four step encoder".
Axel S. schrieb: > brauchst du also nur einen dieser anderen 3 > Zustandsübergänge zum Herauf- bzw. Herunterzählen des Geber-Wertes zu > verwenden. Zweckmäßigerweise nimmst du den Übergang in der Mitte (Z2 <-> > Z3). Gut, danke, dann war das mein Verständnisfehler bisher. Ich hatte für mich vorausgesetzt, dass ALLE dieser 4 Zustände durchlaufen sein MÜSSEN, damit ich von einer erfolgreichen Drehung ausgehen kann. Wenn ich aber einmal in der Mitte auswerten soll, dann kann es vielleicht klappen. Ich muss mir dann nur Gedanken machen, wie ich den Zustand initialisiere. (Weiß ich zum Startpunkt nämlich nicht oder?) und wie ich mit Fehlern umgehe: Wenn nämlich irgendwann ein unerlaubter Zustandswechsel auftritt und ich es resetten möchte, weiß ich nicht, wo ich stehe. Weil wahr sind nur die Wechsel und nicht die absoluten Zustände.
:
Bearbeitet durch User
Angehängte Dateien:
-
encoder.png
17 KB
Axel S. schrieb: > Der Code im Artikel Drehgeber kann das übrigens alles. Mit den dort > gewählten Worten ist dein Encoder ein "four step encoder". Das in diesem Artikel gewählte Beispiel ist eben für mich nicht gültig. Bei diesem sind die Rasterpunkte auf stabilen Zuständen, bei meinem Encoder genau auf einer Flanke! Also undefiniert. Siehe Bild von meinem Encoder oben.
:
Bearbeitet durch User
Solocan Z. schrieb: > Sind die Encoder absoluter Müll Ja, schrecklich, die Hersteller sind alle dumm und dreist. Solocan Z. schrieb: > oder habe ich einen Verständnisfehler Wohl eher. Bei korrekter Auswertung eines Drehgebers stört das Verhalten kein bischen. Daher sind die alle so gebaut. http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 Solocan Z. schrieb: > Siehe Bild von meinem Encoder oben. Man kann Signal A per Hardware entprellen und Signal B dann zur Richtungsentscheidung nutzen oder alle 4 Positionen durch sampling erfassen und geschickt durch 2 teilen und bekommt dieselbe Positionsauflösung.
MaWin schrieb: > Ja, schrecklich, die Hersteller sind alle dumm und dreist. Ne, stellen sondern auch Encoder für andere Zwecke her, die für meine Anwendung ggf. Müll sind. Ist aber wohl nicht der Fall, stimmt. MaWin schrieb: > Wohl eher. Bei korrekter Auswertung eines Drehgebers stört das Verhalten > kein bischen. Daher sind die alle so gebaut. Offensichtlich nicht. Es gibt welche mit stabilen eingerasteten Zuständen und instabilen. MaWin schrieb: > Man kann Signal A per Hardware entprellen und Signal B dann zur > Richtungsentscheidung nutzen Entprellung hat nichts, rein gar nichts mit dem Thema zu tun. Meine sind auch wunderbar hardwareentprellt und gibt's kein Flackern. Hat aber nichts mit dem problem zu tun. MaWin schrieb: > oder alle 4 Positionen durch sampling erfassen und geschickt durch 2 > teilen und bekommt dieselbe Positionsauflösung. Dass dieser naiver Ansatz nicht funktioniert, habe ich eben festgestellt und oben ausführlich beschrieben, warum es bei solchen Encodern nicht funktioniert.
Solocan Z. schrieb: > Axel S. schrieb: >> brauchst du also nur einen dieser anderen 3 >> Zustandsübergänge zum Herauf- bzw. Herunterzählen des Geber-Wertes zu >> verwenden. Zweckmäßigerweise nimmst du den Übergang in der Mitte (Z2 <-> >> Z3). > > Gut, danke, dann war das mein Verständnisfehler bisher. Ich hatte für > mich vorausgesetzt, dass ALLE dieser 4 Zustände durchlaufen sein MÜSSEN, > damit ich von einer erfolgreichen Drehung ausgehen kann. Das verstehst du immer noch falsch. Die Zustandsmaschine soll schon alle 4 Zustände erfassen und nur bei korrekter Reihenfolge zählen. Nur ist das, was die Zustandsmaschine zählt, nicht der zum restlichen Programm hin sichtbare Geber-Wert. Denn der sollte sich von Rastpunkt zu Rastpunkt nur um +1 oder um -1 ändern. Solocan Z. schrieb: > Axel S. schrieb: >> Der Code im Artikel Drehgeber kann das übrigens alles. Mit den dort >> gewählten Worten ist dein Encoder ein "four step encoder". > > Das in diesem Artikel gewählte Beispiel ist eben für mich nicht gültig. > Bei diesem sind die Rasterpunkte auf stabilen Zuständen, bei meinem > Encoder genau auf einer Flanke! Also undefiniert. Dann vertausche die Anschlüsse A und B deines Encoders. Oder verwende gleich den Code aus dem Abschnitt "Drehgeber mit wackeligen Rastpunkten". Wenn du da die Decoder-Tabelle mal als 4x4 Matrix formatierst, siehst du auch gut, bei welchen Zustandsübergängen um +1 bzw. -1 gezählt wird. Und du kannst die Tabelle notfalls auch anpassen.
Axel S. schrieb: > Das verstehst du immer noch falsch. Die Zustandsmaschine soll schon alle > 4 Zustände erfassen und nur bei korrekter Reihenfolge zählen. Nur ist > das, was die Zustandsmaschine zählt, nicht der zum restlichen Programm > hin sichtbare Geber-Wert. Denn der sollte sich von Rastpunkt zu > Rastpunkt nur um +1 oder um -1 ändern. Das ist klar. Zustandsmaschine soll schon alle Zustände erfassen und bei korrekter Reihenfolge zählen. Aber was er zählt ist hier die Frage. Beim Beispiel im Artikel wird einfach das Zählen beim Z1->Z4 und Z4->Z1 weggeschmissen, da dies unbrauchbar ist. Es zählt also nur bei Z2->Z3 und Z3->Z2. Mehr magic ist da nicht.
Solocan Z. schrieb: > Axel S. schrieb: >> Das verstehst du immer noch falsch. Die Zustandsmaschine soll schon alle >> 4 Zustände erfassen und nur bei korrekter Reihenfolge zählen. Nur ist >> das, was die Zustandsmaschine zählt, nicht der zum restlichen Programm >> hin sichtbare Geber-Wert. Denn der sollte sich von Rastpunkt zu >> Rastpunkt nur um +1 oder um -1 ändern. > > Das ist klar. Zustandsmaschine soll schon alle Zustände erfassen und bei > korrekter Reihenfolge zählen. Aber was er zählt ist hier die Frage. Eigentlich ist die Frage, wann gezählt wird. > Beim > Beispiel im Artikel wird einfach das Zählen beim Z1->Z4 und Z4->Z1 > weggeschmissen, da dies unbrauchbar ist. Es zählt also nur bei Z2->Z3 > und Z3->Z2. Fast. Im Artikel Drehgeber ist das Impulsdiagramm (und der Code) für einen Drehgeber mit zwei Rastpunkten pro Zyklus. Da muß man bei jedem zweiten Zustandsübergang zählen, wenn man ein Inkrement/Dekrement pro Rastpunkt haben will. Je nach mechanischer Auslegung des Encoders sind entweder alle 4 Übergänge stabil oder nur zwei. Entsprechend wählt man die Zustandsübergänge so aus, daß sie möglichst weit von einem evtl. instabilen Rastpunkt liegen. Was in der Praxis einfach dadurch erledigt wird, daß man die Phasen vertauscht. Dein Encoder hat aber sogar nur einen Rastpunkt pro Zyklus. Es kann demnach nur einer von 4 Zustandsübergängen instabil sein. Jeder der anderen 3 wäre geeignet, um zu zählen. In der Decoder-Matrix darf für deinen Drehgeber nur eine +1 und nur eine -1 stehen. Nicht zwei wie im Artikel.
Solocan Z. schrieb: > Sind die Encoder absoluter Müll oder habe ich einen Verständnisfehler? > Oder was mache ich falsch? Hallo, ich hatte so ähnlich mit China-Drehgeber. Ein gutes Ergebnis habe ich mit Variante von Herrn Dannegger bekommen (https://www.mikrocontroller.net/articles/Drehgeber#Beispielcode_in_C), wenn ich statt
1 | const char table[16] PROGMEM = {0,0,-1,0,0,0,0,1,1,0,0,0,0,-1,0,0}; |
1 | const char table[16] PROGMEM = {0,0,-1,0,0,0,0,1,0,0,0,0,0,0,0,0}; |
benutzte. Viele Grüße.
:
Bearbeitet durch User
Ja, in der Tabellenvariante kann man bequem auswählen, wann gezählt wird.
Solocan Z. schrieb: > Dass dieser naiver Ansatz nicht funktioniert, habe ich eben festgestellt > und oben ausführlich beschrieben, warum es bei solchen Encodern nicht > funktioniert Da du offenkundig zu blöde bist, den verlinkten keineswegs naiven sonder fachlich treffenden Erklärungen zu folgen und sie zu lesen und zu verstehen, wird das auch so bleiben.
Ich kann dir ganz klar bestätigen das die Tabellenvariante zum Ziel führt. Es hat mich auch ein wenig Zeit gekostet den Artikel für mich auszuarbeiten aber dort steht eigentlich für jeden Drehgebertyp der mir untergekommen ist auch der entsprechende Code. Insbesondere dein Typ ließ sich nur mit der Tabellenvariante verwenden und auch der Anschluß der Phasen ist hier eben nicht egal. Ansonsten würde ich empfehlen einen anderen Drehgeber zu verwenden.
MaWin schrieb: > Solocan Z. schrieb: >> Dass dieser naiver Ansatz nicht funktioniert, habe ich eben festgestellt >> und oben ausführlich beschrieben, warum es bei solchen Encodern nicht >> funktioniert > > Da du offenkundig zu blöde bist, den verlinkten keineswegs naiven sonder > fachlich treffenden Erklärungen zu folgen und sie zu lesen und zu > verstehen, > wird das auch so bleiben. Schimpf bitte beim nächsten Aldi Parkplatz rum und nimm nicht dieses Forum in Geisel.
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.