Hallo, https://www.mikrocontroller.net/articles/Drehgeber Ich habe meinen Alps EC11 Drehgeber mal wieder rausgeholt und teste den "wackeligen Rastpunkte" Code von Peter D. Ich habe das Datenblatt zum Alps gelesen und habe die Signale ausgemessen. Wenn ich von oben draufschaue und die A C B Anschlüsse unten sind, zu mir zeigen, ist A links. Ich bin mir absolut sicher das Phase A auch Phase A ist und Phase B auch Phase B ist. Denn laut Peters Text soll man die Phasen nicht vertauschen. Laut Oszi eilt A der B vor wenn ich CW dreht. Also alles richtig. Nur warum zählt er dann rückwärts wenn ich CW drehe? Bevor ich den Code anpasse wollte ich fragen ob ich etwas übersehe oder ob die falsche Zählrichtung übersehen wurde? Ich kann es mir eigentlich nicht vorstellen aber es ist wie es ist. Da man die Phasen nicht vertauschen soll, würde ich die Tabelle ändern. Oder liegst am EC11 das die Rastpunkte verschoben sind, Produktionsfehler o.ä., sind ja Billigteile, sodass ich doch die Phasen gefahrlos vertauschen kann. Ich welche Richtung zählt er bei euch wenn ihr CW dreht?
:
Bearbeitet durch User
Oh, interessant. Aktuell haben wir ein Projekt, in dem der STEC11B13 verbaut ist, den es nicht mehr gibt, und "alle anderen passenden Schalter" (lies: die zwei oder drei, die wir getestet haben) drehen am Gerät falschrum (CW=- statt CW=+), also muss Layoutmäßig A & B vertauscht werden, um die Ersatzteilverwendbarkeit des Eingabegeräts sicherzustellen. Dreht der EC11-Schalter nonstandard? Und: Was sollte es die Software interessieren ob A A ist oder B? o.g. Problem ergibt sich nur, weil der Kunde ein Board mit dem Dreher hat, das eine festgelegte Steckbelegung hat, und wenn man A & B tauschen würde wäre alles gut. Kann der Endkunde aber nicht, also muss das Steckkompatibel werden. Also "Rev 2.0" mit gekreuzten Leiterbahnen, mehr nicht.
Frage Dazu verwendest du den Drehgeber in Activ Low oder Aktiv High? Sprich du hast [C] auf (+) oder (GND) ? und die Widerstände entsprechend gegenpolig? Je nach dem kehrst du dabei die Zähl-Phase ;-)
Hallo,
wenn ich rein die Phasensignale betrachte sollte es vollkommen egal sein
wie man diese herum anklemmt. Nur wenn ich Peters Text richtig verstehe
geht es bei wackligen bzw. ausgeleierten Dingern darum die "bessere"
Phase zu zählen weil die Ungünstige sonst auf dem blöden Rastpunkt
liegt. Also genau eine wechselnde Flanke liegt bei den Billigteilen
blöderweise auf den Rastpunkten.
> Dreht der EC11-Schalter nonstandard?
Keine Ahnung. Habe EC11 mit EC12 verglichen. Laut Datenblatt identisch
in der Beziehung. EC13 habe ich nicht gefunden.
@ Patrick
C ist auf Masse > aktiv Low. Es ist jedoch egal ob die Signale
invertiert sind oder nicht. Die wandern dennoch richtig "vorbei". Es
kommt nur darauf an welche Phase der Anderen voreilt. Ich haben Peters
Code so wie er ist (barmetal C) auf einem Arduino Mega2560 getestet. Und
ich habe ich ihn auf einen Nano Every angepasst mit eigenen Libs wo ich
im µC per Register das I/O Signal invertieren kann. ATmega4809. Es
ändert alles nichts. Zählt rückwärts bei CW drehen. Den Gedanken hatte
ich Anfangs auch gehabt. :-)
Das macht mich nun wuschig weil ich kaum glaube das Peter einen Code
schreibt der CW rückwärts zählt. Deswegen meine Forumsfrage.
:
Bearbeitet durch User
Veit D. schrieb: > Das macht mich nun wuschig weil ich kaum glaube das Peter einen Code > schreibt der CW rückwärts zählt. Deswegen meine Forumsfrage. Wenn dich das so wuschig macht, nimm Stift und Zettel, und simuliere das mal kurz durch. Dann müsstest du nichts mehr glauben, dann wüsstest du, was los ist. Dauert keine 5 Minuten, und wäre schneller gewesen als die ganze Tipperei hier im Forum. Oliver
Hallo, laut Stift und Papier zählt es laut Peters 'table' CW rückwärts. Wenn Phase A voreilt. Ja. Aber das war nicht die Frage. Ich kann mir immer noch schwer vorstellen warum Peters Code absichtlich rückwärts zählen sollte. Scheinbar ist das doch verdreht im Code. Nur die Verwunderung muss ja nachgefragt werden dürfen.
Veit D. schrieb: > C ist auf Masse > aktiv Low. das ist aber dann active high. Üblicherweise macht man das genau anders rum.
Hallo, ne. Ruhezustand durch Pullup ist High, wenn Kontakt geschlossen wird zieht er das Signal auf Masse -> Aktiv Low. Ob aktiv Low oder aktiv High spielt auch generell keine Rolle. Es kommt darauf an welche Phase voreilt. Das bestimmt die Zählrichtung.
:
Bearbeitet durch User
Veit D. schrieb: > Ob aktiv Low oder aktiv High spielt auch generell keine Rolle. Es kommt > darauf an welche Phase voreilt. Das bestimmt die Zählrichtung. Hier is wichtig die richtige Phase, also die die nicht wackelt, auszuwerten. Deshalb macht zur Richtungsumkehr, eine Vertauschung der Phasen, keinen Sinn. Sollte das Wackeln nicht aufhören, dann natürlich schon. Also wars dem Peter sicher wurscht, wierum der gezeigte Code zählt.
Hallo, eigentlich hatte ich erhofft das Peter dazu etwas sagen könnte. Ich kann von außen nicht feststellen ob A oder B sauberer/stabiler auf dem Rastpunkt liegt. Sobald ich einen Hauch drehe reagiert die eine Phase und bin ich am nächsten Rastpunkt reagiert die andere Phase. Ich weiß also nicht welche Phase auf dem Rastpunkt pendeln könnte. Im dümmsten Fall beide. Nur genau das ist laut Peters Beschreibung wichtig zu wissen. Ansonsten wäre man gezwungen nach x Stunden Betriebsdauer den Code zu ändern wenn der Encoder plötzlich ausleiert. Oder es ist wirklich vollkommen egal wo welche Phase liegt. Nur dann würde Peter nicht soviel Wert darauflegen. Soweit kreisen meine Gedanken.
Jens M. schrieb: > Und: Was sollte es die Software interessieren ob A A ist oder B? Genau die Software wird es interessieren, wenn auf der Rastposition ein Signal nicht stabil ist. In der EC11-Serie liegen bei einigen Typen die Umschaltpositionen bei der Rastpositionen - sagt das Datenblatt beim Thema "Output Wave".
Hallo, @ Teo: Okay. Nur wie bekommt man das im Vorfeld raus wenn der Encoder noch frisch ist?
Veit D. schrieb: > Ob aktiv Low oder aktiv High spielt auch generell keine Rolle. Es kommt > darauf an welche Phase voreilt. Das bestimmt die Zählrichtung. das ist richtig, was aber voreilt hängt davon ab ob C gegen VCC oder GND geht. Anders ausgedrückt vor/nach eilend, und damit die Richtung, wird durch die Auswertelogik bestimmt. Patrick hat das ja schon geschrieben. Ich kenn das halt so C gegen Vcc mit Pulldowns an A/B, das hat für mich bisher immer gepasst
Veit D. schrieb: > Also genau eine wechselnde Flanke liegt bei den Billigteilen > blöderweise auf den Rastpunkten. Echt jetzt? Was ein Schrott... Veit D. schrieb: > Nur genau das ist laut Peters Beschreibung wichtig zu > wissen. Dann wird er den Code für einen Encoder geschrieben haben, der pro Raste einen kompletten Schritt macht.
Ich würde die Signale "Latchen" so löse ich dies wenn ich Pulscoder verwende. Das heißt das "B" muss sich geändert haben bevor ein neues "A" akzeptiert wird und umgekehrt. so ist egal wie viel mal der Kontakt prellt.
Hallo, @ Thomas: ne ne ne, es ist vollkommen egal ob das Signal negiert ist oder nicht. Eins eilt immer dem Anderen voraus bzw. nach. Und irgendwann sind auch positiven Flanken wieder dran und eine eilt vor. Male es auf oder probiere es aus. Die Verschiebung ist identisch nur zeitlich im Gesamten! verschoben und damit egal. @ Jens: Lies einmal den Text vom Peter. Der 2 Schritt Code, halbe Auflösung passt zu den billigen EC11 Typen und vergleichbare. Der 4 Schritt Code, volle Auflösung passt zu den teueren Typen. Pro Rastung ein Zählschritt. Von den 4 Schritt habe ich auch einen da. Alps EM20B. Der zählt genauso mit CW falsch herum. Nur kann ich bei Letzterem die Phasen gefahrlos tauschen, weil der leiert nicht aus.
Patrick L. schrieb: > Das heißt das "B" muss sich geändert haben bevor ein neues "A" > akzeptiert wird und umgekehrt. so ist egal wie viel mal der Kontakt > prellt. Und was stört dich am Prellen? Bei Gray-Code hat das keinen störenden Einfluss auf den Wert, wenn man mal davon absieht, dass der Wert während des Prellens hin und her springt.
Veit D. schrieb: > Hallo, > > @ Teo: > Okay. Nur wie bekommt man das im Vorfeld raus wenn der Encoder noch > frisch ist? So rein Theoretisch, ich hatte noch kein solchen Kandidaten. Gib ihm nur ~100µA zum schalten oder nach "Bedarf" auch weniger.
Jens M. schrieb: > Dann wird er den Code für einen Encoder geschrieben haben, der pro Raste > einen kompletten Schritt macht. Du meinst: zwei Schritte. Normalerweise bezeichnet man den Pegelwechsel eines der Phasensignale als Schritt. Hat wenig bis nichts mit Rastpunkten zu tun. Es gibt Encoder, die halt zwischen zwei Rastpunkten nur einen Schritt machen, welche, die zwei Schritte machen und welche, die nichtmal Rastpunkte besitzen... Was PeDas Code betrifft: wenn ich den richtig in Erinnerung habe, ist er diesbezüglich konfigurierbar, man kann also für die Dinger, die zwei Schritte pro Rastpunkt machen, sagen, dass nach außen nur ein Schritt gemeldet werden soll, so dass also im Endeffekt statt Schritte Rastpunkte gezählt werden.
Wolfgang schrieb: > Gray-Code Ja nur geht es hier nicht um Gray-Code. Eine simple Clock ->U/D schaltung ist nicht Praktikabel bei diesen Reglern. Deshalb löse ich dies immer per Interrupt und Flag's das heist beide (A+B) werden mit einem Interrupt abgefragt und (Int A braucht immer ein Vorhergehenden Int B das heißt ist ein Interuppt aufgetreten muss zuerst der andere Int auftreten bevor der Int wieder aktiv ist Int A-> Disable Int A & Enable Int B Int B-> Disable Int B & Enable Int A Die Interrupts sind änderungsaktiv, das heißt es muss eine Flanke kommen um ein Interrupt auszulösen. Entweder H->L oder L-H je nach dem wo das Signal liegt. Die Int-Reihenfolge gibt dann die Drehrichtung(Zählrichtung) an. Forteil ich verbrauch keine Abfrage-Zeit, weil ich die Pins nicht dauernd kontrollieren muss.
Teo D. schrieb: > Veit D. schrieb: >> Hallo, >> >> @ Teo: >> Okay. Nur wie bekommt man das im Vorfeld raus wenn der Encoder noch >> frisch ist? > > So rein Theoretisch, ich hatte noch kein solchen Kandidaten. > Gib ihm nur ~100µA zum schalten oder nach "Bedarf" auch weniger. Werde ich ausprobieren und mich dann davon abhängig entscheiden was ich mache. Im "schlimmsten Fall" erweitere ich den Code um einen weiteren Parameter. Dann kann man die Phasen im Nachgang im Code vertauschen so das ausgeleierte Encoder sich nicht mehr verzählen und je nachdem kann man zusätzlich die Zählrichtung wiederum dem anpassen. Ich glaube das wäre optimal. Danke fürs zuhören und mitmachen.
Du brauchst eh' eine einstellbare Möglichkeit, die Zählrichtung ändern zu können (spätestens wenn es nachbausicher werden soll). Bei den billigen Encodern, die wie Alphs EC11 aussehen, variiert die Phasenlage des A-B-Signals je nach Charge.
:
Bearbeitet durch User
Veit D. schrieb: > Dann kann man die Phasen im Nachgang im Code vertauschen so > das ausgeleierte Encoder sich nicht mehr verzählen und je nachdem kann > man zusätzlich die Zählrichtung wiederum dem anpassen. Ich glaube das > wäre optimal. Ersteres macht keinen Sinn, da müsstest du die Phasen tauschen und die Drehrichtung im Code korrigieren. Was uns zu Punkt zwei bring. Das ist doch bereits im Code vorhanden!
Patrick L. schrieb: > Ja nur geht es hier nicht um Gray-Code. Was macht denn so ein A/B-Encoder sonst?
Hallo, Teo. Warum soll das keinen Sinn machen? Wenn man im Vorfeld nicht herausfinden kann welche Phase besser im Rastpunkt liegt, dann ist man gezwungen die Phasen später im Code zu tauschen wenn er nach x Stunden ausgeleiert ist. Durch das tauschen der Phasen ändert sich die Zählrichtung. Deswegen muss man diese wiederum korrigieren. Ich denke meine Denkweise passt da schon.
:
Bearbeitet durch User
Evtl. reden wir auch nur aneinander vorbei. Die Praxis wird schon zeigen. Viel Kombinationsmöglichkeiten gibts ja nich. :)
Wolfgang schrieb: > Patrick L. schrieb: >> Ja nur geht es hier nicht um Gray-Code. > > Was macht denn so ein A/B-Encoder sonst? Da muss ich Patrick schon recht geben. Ein Gray Code sieht anders aus als das was die Encoder liefern. Der Alps EC11 zum Bsp. liefert nahezu 2 identische Signalverläufe nur zeitlich verschoben. Das gibts im Graycode nicht. Im Graycode hat die nächste Spur immer die doppelte Periodendauer der Vorherigen. Bzw. umgekehrt je nach Blickwinkel. ;-) @ Teo: Bestimmt. Die Möglichkeiten sind übersichtlich. :-)
:
Bearbeitet durch User
Veit D. schrieb: > Da muss ich Patrick schon recht geben. Ein Gray Code sieht anders aus > als das was die Encoder liefern. Da täuscht du dich. Erstens gibt es nicht DEN Gray-Code, sondern damit wird eine ganze Klasse von Codes bezeichnet. Die zeichnen sich dadurch aus, dass der Hammingabstand benachbarter Code-Worte genau eins ist, d.h. es ändert sich an einem Umschaltpunkt genau ein Bit. Das ist bei so einem Encoder genau der Fall. Dadurch, dass so ein Ding nur einen zwei Bit Code erzeugt, ergeben sich bei der Codespiegel die genau gleichen, phasenverschobenen Signale. In dem Beispiel aus Wikipedia mit dem periodischen 3-Bit Code siehst du das bei den inneren beiden Bits. https://de.wikipedia.org/wiki/Datei:BCD-Scheibe.svg
Hallo, ja okay, es gibt verschiedene Möglichkeiten. Mein Blick war zu eng. :-)
>Nur warum zählt er dann rückwärts wenn ich CW drehe?
Weil mathemarisch die positive Drehrichtung CCW ist?
Hallo Peter D. falls du hier mitliest. Das war keine Kritik, dass waren nur Fragen zum tieferen Verständnis. Die Tabelle mit den Dummywerten usw. ist und bleibt genial. Dankeschön dafür.
Veit D. schrieb: > Der Alps EC11 zum Bsp. liefert nahezu 2 > identische Signalverläufe nur zeitlich verschoben. Das gibts im Graycode > nicht. Doch. Im vollständigen Graycode sind die beiden höchstwertigen Bits verschoben und haben die gleiche Periodendauer. Daneben gibt es noch Graycodes, die nicht alle Binärwerte enthalten. Das wesentliche Merkmal eines Graycodes ist nämlich, daß sich immer nur ein Bit ändern darf.
c-hater schrieb: > Du meinst: zwei Schritte. Normalerweise bezeichnet man den Pegelwechsel > eines der Phasensignale als Schritt. Ich kenn das als Halbschritt. Ein Schritt ist, wenn die Signale wieder so sind wie vorher. also - A&B sind Low, der Knopf eingerastet - weiterdrehen: - A kommt - B kommt - A geht - B geht - der Knopf rastet wieder ist ein Schritt. Dadurch hat man stabile Positionen und keine wackeligen Signale bloß weil mal eine Fliege auf dem Knopf sitzt oder ein Krümel Fett die Rastung 3 hunderstel wegdrückt. Allerdings sind die Kontakte dann wohl recht fein, weswegen ausgerechnet billige Encoder gröbere Raster benutzen und dann an o.g. Problemen leiden.
Veit D. schrieb: > wenn ich rein die Phasensignale betrachte sollte es vollkommen egal sein > wie man diese herum anklemmt. Nö. Nicht vollkommen. Das gilt nur für den inneren Algorithmus. Bei gar vielen Drehgebern kommt nämlich noch die Ausrichtung der Rastungen hinzu. Und plötzlich kann es dir passieren, daß ein Signalwechsel mitten in der Rastung oder sehr knapp daneben passiert. W.S.
Hallo, @ W.S. Das ist leider komplett aus dem Zusammenhang gerissen. Und wo die Rastpunkte liegen hat mit der Zählrichtung überhaupt nichts zu tun. @ Peter: Das es verschiedene Arten von Graycodes gibt habe ich mittlerweile verstanden. :-) Danke.
:
Bearbeitet durch User
Hallo, ich muss nochmal nachhaken, denn mein eigentliches Anliegen kam irgendwie noch nicht so richtig zur Sprache. Es geht mir um die Doku die mich wuschig macht. > Die solide Lösung des Problems ist recht einfach. Man wertet in der > bekannten Manier weiterhin die abgetasteten Spuren A und B aus, > allerdings mit der Änderung, dass man nur die Pegelwechsel der Spur A > auswertet. Damit halbiert man zwar die Auflösung, das ist hier aber > paradoxerweise gut! Denn damit bekommt man automatisch genau einen > Zählimpuls pro Rastpunkt. Da man bei wackligen Kanditaten nicht weiß, wegen schlechter Fertigungsqualität, welche Spur nun wirklich Probleme macht, sollte es bestimmt besser lauten. "... allerdings mit der Änderung, dass man nur die Pegelwechsel EINER Spur auswertet." Ohne explizite Spurangabe. Allein schon deswegen weil man die Zählrichtung anpassen können muss. Wobei das für meine Interpretation auch noch nicht stimmt, denn es werden dennoch beide Spuren zur Logikbestimmung im Code verwendet um auf den korrekten Index der Tabelle zu kommen. Es wird NICHT immer nur ein und dasselbe Bit einer Spur für die Logikauswertung verwendet. Kann man jetzt mein Leseproblem nachvollziehen?
:
Bearbeitet durch User
Veit D. schrieb: > @ W.S. > Das ist leider komplett aus dem Zusammenhang gerissen. > > Und wo die Rastpunkte liegen hat mit der Zählrichtung überhaupt nichts > zu tun. Nö, denn es war meine Antwort auf > Veit D. schrieb: >> wenn ich rein die Phasensignale betrachte sollte es vollkommen egal sein >> wie man diese herum anklemmt. Es ist eben nicht egal, sondern von praktischer Bedeutung (je nach DG-Typ). Wenn man es verkehrt herum anklemmt, kriegt man andauernde V/R-Ereignisse im Ergebnis - sonst eben nicht. Aber daß es dem inneren Algorithmus egal ist, hatte ich ja schon geschrieben. W.S.
Beitrag #6793770 wurde vom Autor gelöscht.
Hallo,
die Betonung liegt auf 'rein' und bezieht sich auf die Antwort von Jens
mit seinem letzten Absatz
> Und: Was sollte es die Software interessieren ob A A ist oder B?
Veit D. schrieb: > die Betonung liegt auf 'rein' und bezieht sich auf die Antwort von Jens > mit seinem letzten Absatz >> Und: Was sollte es die Software interessieren ob A A ist oder B? Warum nur, löschen die Leute bei Ihren Zitaten, den Link raus? Weil's besser aussieht?-O Ich werde nicht auf die Suche gehen! Veit D. schrieb: > Wobei das für meine Interpretation auch noch nicht stimmt, denn es > werden dennoch beide Spuren zur Logikbestimmung im Code verwendet um auf > den korrekten Index der Tabelle zu kommen. Es wird NICHT immer nur ein > und dasselbe Bit einer Spur für die Logikauswertung verwendet. (Ich kenn seinen Code nicht wirklich!!!) Der Unterschied ist, ob man auf den Pegelwechseln von beiden Spuren reagiert und den Zustand auswertet, oder nur auf dem von einer. Bei Letzterem, zappelts halt nicht, man verliert höchsten einen Schritt/Rastung.
Jens M. schrieb: > Ich kenn das als Halbschritt. > Ein Schritt ist, wenn die Signale wieder so sind wie vorher. > also > - A&B sind Low, der Knopf eingerastet > - weiterdrehen: > - A kommt > - B kommt > - A geht > - B geht > - der Knopf rastet wieder > ist ein Schritt. Nö, so scheisse sind nichtmal Billigencoder. Das wären ja vier Schritte zwischen zwei Rastpunkten. Hab' noch keinen Encoder gesehen, der das so macht. Schließt natürlich nicht aus, dass es solche gibt, denn physikalisch wäre es natürlich möglich. Was du scheinbar nicht begiffen hast: Rastpunkte in größerem Abstand als dem echten/einfachen Schrittabstand haben nur einen einzigen Zweck: die Mechanik billig zu halten. Dafür genügt aber bereits, sie zwei Schritte zwischen den Rastpunkten machen zu lassen, vier bringen keinen weiteren Vorteil mehr bezüglich der Kostenreduktion, aber halbieren erneut die physikalische Auflösung (wie auch das übliche Verfahren mit zwei Schritten pro Rastpunkt es bereits tut). Weil das so ist, kann ich mir nicht vorstellen, dass es tatsächlich Encoder mit dem von dir beschriebenen Verhalten geben soll. Ich lasse mich aber gern vom Gegenteil überzeugen. Datenblatt-Link für so ein Teil?
Teo D. schrieb: > Veit D. schrieb: >> die Betonung liegt auf 'rein' und bezieht sich auf die Antwort von Jens >> mit seinem letzten Absatz >>> Und: Was sollte es die Software interessieren ob A A ist oder B? > > Warum nur, löschen die Leute bei Ihren Zitaten, den Link raus? Weil's > besser aussieht?-O Ich werde nicht auf die Suche gehen! Naja, dass geht dich ja nichts an, weil das schon lange geklärt ist. Das ist rumreiten auf alten Kamellen. W.S. hat mittendrin eine Aussage von mir gefunden ohne von vorn den Thread zu lesen. Genau das ist sein Problem und nun muss ich das geradebiegen. Sowas ist sinnlos, mühsam und sinnfrei. > Veit D. schrieb: >> Wobei das für meine Interpretation auch noch nicht stimmt, denn es >> werden dennoch beide Spuren zur Logikbestimmung im Code verwendet um auf >> den korrekten Index der Tabelle zu kommen. Es wird NICHT immer nur ein >> und dasselbe Bit einer Spur für die Logikauswertung verwendet. > > (Ich kenn seinen Code nicht wirklich!!!) Naja, hatte ich verlinkt. :-) Nochmal. https://www.mikrocontroller.net/articles/Drehgeber > Der Unterschied ist, ob man auf den Pegelwechseln von beiden Spuren > reagiert und den Zustand auswertet, oder nur auf dem von einer. Bei > Letzterem, zappelts halt nicht, man verliert höchsten einen > Schritt/Rastung. Ich weiß echt nicht mehr wie ich es noch formulieren soll. Wo liegt das Kommunikationsproblem? Ich halte die Aussage das nur eine Spur ausgewertet wird für falsch. In allen Fällen. Man kann nicht nur eine Spur auswerten, denn dann erkennt man keine Drehrichtung. Auch im "wackligen Code" werden beide Spuren eingelesen und ausgewertet damit man auf den richtigen Index in der Tabelle kommt. Das geht gar nicht anders. Der Unterschied ist nur ob man jede Bit-Änderung zum zählen verwendet oder jede Zweite oder jede Vierte. Versteht man mich worauf ich hinaus möchte? Man kann auch Peters Code davor nehmen und das Endergebnis um eins nach rechts schiften. Wäre auch halbiert für 2 Schritte pro Rastpunkt. Dennoch muss man vorher beide Spuren auswerten usw. @ c-hater > Das wären ja vier Schritte zwischen zwei Rastpunkten. Hab' noch keinen > Encoder gesehen, der das so macht. Schließt natürlich nicht aus, dass > es solche gibt, denn physikalisch wäre es natürlich möglich. Ich habe so einen. Alps EM20B. Der prellt nicht. https://tech.alpsalpine.com/e/delete/em20b.html
:
Bearbeitet durch User
Veit D. schrieb: > Wo liegt das Kommunikationsproblem? Das, wenn man die Ereignisse Flanke/Pegel und nach welchen dieser Ereignisse, die eigentliche Auswertung erfolgt, nicht differenzieren will, hast Du ja recht.
Veit D. schrieb: > Ich habe so einen. Alps EM20B. Der prellt nicht. Kein Kunststück. Wenn man vier Schritte zwischen zwei Rastpunkten macht (falls das wirklich so ist, dem DB it das nicht direkt zu entnehmen) und obendrein statt mechanischer Kontakte Hall-ICs benutzt, kann das wohl jeder. Der schiere Platzbedarf der Sensoren und die Tatsache, dass sie sich auf einer Ebene befinden müssen, um die Kosten nicht noch weiter in die Höhe zu treiben, dürfte übrigens der Grund dafür gewesen sein, hier das sehr ungewöhnliche Schema mit 4 Schritten pro Rastpunkt zu verwenden (falls das wirklich so ist). Wie auch immer, das Teil war (zu seiner Zeit) definitiv sicher kein Billigprodukt, sondern was Gutes mit entspechendem Preis. Und dieser Preis und die daraus resultierenden Absatzprobleme dürften wohl zum im verlinkten DB dokumentierten Status eines "deleted product" geführt haben...
Hallo, @ c-hater Komm, du wirst wohl mit den Angaben Numbers of detent und Numbers of pulse klarkommen? @ Teo Tut mir leid. Das musst du neu formulieren. Der Satz ist mir zu durcheinander. Da ist alles reininterpretierbar was geht.
Veit D. schrieb: > @ c-hater > Komm, du wirst wohl mit den Angaben Numbers of detent und Numbers of > pulse klarkommen? Nicht wirklich. Numbers of detent ist klar und eindeutig. Aber numbers of pulse nicht. Mir scheint, dass hier eigentlich "numbers of edge" gemeint ist. Also das, was normalerweise als "Schritt" bezeichnet wird: die kleinstmögliche Änderung des Systemzustands und damit das Maximum der erreichbaren Auflösung.
c-hater schrieb: > Ich lasse mich aber gern vom Gegenteil überzeugen. Datenblatt-Link für > so ein Teil? ACZ11BR1E-20FD1-12C, Digikey 102-1760-ND, aber Grundsätzlich macht das jeder Schalter, der PPR und Detents gleicht hat. Ist halt stabil und easy auszuwerten, billig, verfügbar, Standard. Der STEC11B13 hat einen halben Durchlauf pro Klick, also beide Signale mit steigenden oder fallenden Flanken. Macht schon Sinn, wenn ein Klick eine Zahl ist, da muss man dann in der Software sagen wie die Flanken ausgewertet werden sollen. Ob man jetzt "jede Flanke", "jede A-Flanke" oder "je einen kompletten Durchlauf" in der Software realisiert
c-hater schrieb: > die > kleinstmögliche Änderung des Systemzustands und damit das Maximum der > erreichbaren Auflösung. Bei einem Schalter mit Detents: ein Detent. Nicht "eine Flanke", "ein Puls", "zwei komplette Pulse", whatever. Der Schalter rastet ein, man kann nicht nur einen halben Detent weiter. Also ist ein Detent ein Schritt. Schalter ohne Detent dagegen haben dann wie von dir beschrieben eine elektrisch bestimmte Auflösung, da kann man "einen Schritt" und "eine Flanke" gleichsetzen.
c-hater schrieb: > Veit D. schrieb: > >> @ c-hater >> Komm, du wirst wohl mit den Angaben Numbers of detent und Numbers of >> pulse klarkommen? > > Nicht wirklich. Numbers of detent ist klar und eindeutig. Aber numbers > of pulse nicht. Mir scheint, dass hier eigentlich "numbers of edge" > gemeint ist. > > Also das, was normalerweise als "Schritt" bezeichnet wird: die > kleinstmögliche Änderung des Systemzustands und damit das Maximum der > erreichbaren Auflösung. Ein Puls ist eine komplette Periode. Das auf 2 Spuren angewandt ergibt 4 Bit Änderungen pro Rastung auf die man schaut. Beim Alps EC11 steht 36 detent und 18 pulse.
Veit D. schrieb: > @ Teo > Tut mir leid. Das musst du neu formulieren. Der Satz ist mir zu > durcheinander. Da ist alles reininterpretierbar was geht. Ne Du, das war mein letzter verzweifelter Versuch. :/ Und aufs evtl. Haare spalten, hab ich schon gar keine Lust.
Hallo, dann rede ich mal Klartext. Du hast erkannt das du Unsinn geschrieben hast. Weil du und viele Andere einfach nur noch Texte überfliegen und dann irgendwas antworten. Auf meine eigentliche Frage wurde nie eingegangen. Es kann doch nicht sein das niemand außer ich Peters Code lesen kann.
1 | ISR( TIMER0_COMP_vect ) { // 1ms fuer manuelle Eingabe |
2 | static int8_t last=0; // alten Wert speichern |
3 | uint8_t tmp; |
4 | |
5 | tmp = ENCODER_PIN; // liest den Port ein |
6 | last = (last << 2) & 0x0F; |
7 | if (tmp & PHASE_A) last |= 2; // Phase_ ist das Port bit |
8 | if (tmp & PHASE_B) last |= 1; |
9 | enc_delta += pgm_read_byte(&table[last]); |
10 | }
|
Daraus ist doch ganz klar erkennbar das beide Phasen/Spuren ausgewertet werden.
1 | if (tmp & PHASE_A) last |= 2; |
2 | if (tmp & PHASE_B) last |= 1; |
und 'last' der Index für den Tabellenzugriff ist. Und dann wollen mir alle erzählen das nur eine Spur ausgewertet wird? Das kann doch nicht wahr sein. Und genau das ist in Peters Beschreibung falsch beschrieben.
:
Bearbeitet durch User
Veit D. schrieb: > Es kann doch nicht sein das niemand außer ich Peters Code lesen kann. Reg dich nicht auf. Ich hab schon so einiges an Drehgebern, Tasten und Tastenmatrizen entprellt, aber dazu noch nie irendwelchen Quellcode von Peter benötigt. Es ist also nicht die Frage, ob jemand Peters Code lesen kann, sondern ob er Peters Code überhaupt benötigt und deshalb lesen sollte. Was mir in den letzten Jahren untergekommen war, fällt hauptsächlich in 2 Gruppen: a) die meisten billigen Drehgeber: - Rastung und Flanke von B - Flanke von A Hierbei wertet man nur die Flanke von A und den Zustand von B während oder ganz kurz nach der Flanke von A aus. Die Flanke ergibt das Eintreten des Dreh-Ereignisses und der Zustand von B während der Flanke von A ergibt die Richtung. b) eine kleinere Gruppe von auch nicht so teuren Drehgebern : - Rastung - Flanke von A - Flanke von B Hierbei ist es schnurz, ob man die Flanke von A und den Zustand von B wie oben auswertet oder die beiden Signale vertauscht. Allerdings setzt diese Signalfolge eine stabilere und verschleißfestere Mechanik als a) voraus, da der Dreh-Abstand zwischen 2 Rastungen gedrittelt ist. Bei a) ist er nur halbiert, das schafft etwas mehr Abstand ggü. Toleranzen und Wackeleien nach Alterung. W.S.
Veit D. schrieb: > Hallo, > > dann rede ich mal Klartext. Hättest Du das mal getan. Veit D. schrieb: > Ich weiß echt nicht mehr wie ich es noch formulieren soll. > Wo liegt das Kommunikationsproblem? > Ich halte die Aussage das nur eine Spur ausgewertet wird für falsch. In > allen Fällen. Man kann nicht nur eine Spur auswerten, denn dann erkennt > man keine Drehrichtung. Ich lese hier leider nirgendwo, das Peters Code anscheinen nicht das macht, wie beschrieben, nur ein allgemeines Unverständnis! Teo D. schrieb: > (Ich kenn seinen Code nicht wirklich!!!) Was glaubst du, warum ich dir diesen Hinweis gab?! .... Keine Ahnung was er da macht. Ich hab keinen Schimmer von AVRs, die Includes sind mir unbekannt, Makros hinter Makros und er scheint die Pins zweimal einzulesen?-\ Die Tabelle drösle ich erst garnicht auf. Sorry und gn8
Veit D. schrieb: > Nur wenn ich Peters Text richtig verstehe > geht es bei wackligen bzw. ausgeleierten Dingern darum die "bessere" > Phase zu zählen weil die Ungünstige sonst auf dem blöden Rastpunkt > liegt Was spricht dagegen, beide auszuwerten? OB das Teil leiert oder nicht, ist doch nur eine Frage, wie sehr die Werte springen, da sie das bei langsem Drehen mit wenig "grip" auch so tun können (Prelleffekt).
Teo schrieb: > Ich hab keinen Schimmer von AVRs, die > Includes sind mir unbekannt, Makros hinter Makros und er scheint die > Pins zweimal einzulesen?-\ Nö. Die Pins werden genau einmal hier eingelesen:
1 | tmp = ENCODER_PIN; |
Die neuen vier möglichen Zustände werden Indexbits 0 ( für Phase B) und 1 (für PHASE A), nachdem der alte Zustand aus dem letzten Durchlauf in die Bits 2 (alte PHASE B) und 3 (alte PHASE A) geschoben wurde. Es ergibt sich ein Index zwischen 0x00 und 0x0F, der sich nun aus der Tabelle den Wert holt, der enc_delta wird. Das kann entweder -1, 0 oder +1 sein.
1 | last = (last << 2) & 0x0F; // letzten Zustand auf Bits 2 und 3 schieben |
2 | if (tmp & PHASE_A) last |= 2; // neues Bit 1 |
3 | if (tmp & PHASE_B) last |= 1; // neues Bit 0 |
4 | enc_delta += pgm_read_byte(&table[last]); |
Und fertig ohne Hexenwerk. Da ist nichts AVR spezifisch ausser dem Zugriff auf das PIN Register des Encoder Ports.
:
Bearbeitet durch User
c-hater schrieb: > Das wären ja vier Schritte > zwischen zwei Rastpunkten. Hab' noch keinen Encoder gesehen, > der das so macht. Schließt natürlich nicht aus, dass es solche gibt, > denn physikalisch wäre es natürlich möglich. solche kaufte ich deswegen wunderte ich mich warum ich #elif defined (Four_Step) int8_t encode_read( void ) // read four step encoders { nehmen musste, aber weils funktioniert freue ich mich. Vermutlich ist das der Grund warum dieser 4step Code auch existiert, sonst gäbe es diesen 4step Code ja nicht wenn er nicht genutzt werden müsste.
:
Bearbeitet durch User
Das mit den Drehgebern, wo sich ein Signal genau auf dem Rastpunkt ändert, ist etwas tricky. Man muß dann den Drehgeber so anschließen, daß eine Änderung des Delta erst bei der Flanke des anderen Signals erfolgt. Ist dann die Zählrichtung falsch, setzt man vor das zu addierende Delta ein Minuszeichen.
Hallo, Danke Peter. Zwar spät aber immerhin. Das wäre die Top Antwort gleich zu Beginn gewesen. :-) Das bestätigt das Ergebnis vom Threadverlauf. So Leute, ich mach jetzt hier Schluss. Danke fürs Gespräch.
> c-hater schrieb: >> Das wären ja vier Schritte >> zwischen zwei Rastpunkten. Hab' noch keinen Encoder gesehen, >> der das so macht. Schließt natürlich nicht aus, dass es solche gibt, >> denn physikalisch wäre es natürlich möglich. Ich hab das z.B. bei den Jog-Shuttle von Videorekordern gesehen, aber die sind ja ausgestorben. https://de.aliexpress.com/item/32495198210.html
Alternativen sind solche die Hallelemente haben die Nutzen nicht ab, haben saubere Flanken, und ein Magnetisches Raster, so dass selbst die Reasterung nicht altert. Kosten aber leider auch entsprechend und werden hauptsächlich bei Industrie Jogwheel eingesetzt. (CNC)
Patrick L. schrieb: > Alternativen sind solche die Hallelemente haben die Nutzen nicht ab, > haben saubere Flanken, und ein Magnetisches Raster, so dass selbst die > Reasterung nicht altert. Ist zwar etwas klobig aber Leute bauen sich sowas (ähnliches) aus alten Schrittmotoren!?
Teo D. schrieb: > Schrittmotoren!? Ja habe ich auch mal Probiert, Und man braucht dazu am µC nur Komparator Eingänge und saubere Schutzdioden, da die Stepper richtig kräftige Peeks produzieren können. Also eine Bat68(2 Seriell Dioden in einem Gehäuse) z.b. die man gerne verwendet, raucht klammheimlich ab ;-)
Teo D. schrieb: > Ist zwar etwas klobig aber Leute bauen sich sowas (ähnliches) aus alten > Schrittmotoren!? Es gibt auch sehr kleine Schrittmotoren (Ebay ist voll davon), wenn man nicht unbedingt 200 Schritt/Umdrehung braucht. Schrittmotoren als Encoder-Ersatz haben aber den Nachteil, dass Schritte verloren gehen, wenn man zu langsam daran dreht.
Yalu X. schrieb: > Schrittmotoren als Encoder-Ersatz haben aber den Nachteil, dass Schritte > verloren gehen, wenn man zu langsam daran dreht Ist Richtig, wobei wenn du kein Lastwiderstand dran hast, musst du wirklich Sehr sehr langsam drehen da die 1.2V die ein Komparator braucht sehr schnell erreicht werden. Problematisch wird aber die Erkennung von Steigend/Fallend. den ein Stepper macht bei einem Stepp, eine volle Pos/Neg oder Neg/Pos Flanke. Wen der Lesezyklus zu Träge ist kann da schon mal eine Flanke verloren gehen. Deshalb Steppe Ja aber immer auf 2 Flanken warten bevor gezählt wird (Also einmal A und einmal B. Man kann mit Hilfe von Komparatoren auch feiner auflösen aber bei feinen Stepps überflüssig. Ich für mein Teil würde mit Hallelementen oder Drehfeld Sensoren arbeiten. Letzteres, gibt dir sogar Auskunft wo der Drehgeber im Moment grad steht.
Yalu X. schrieb: > Schrittmotoren als Encoder-Ersatz haben aber den Nachteil, dass Schritte > verloren gehen, wenn man zu langsam daran dreht. Wieso das?
stell mal die Uhr in deinem Rechner richtig, oder wieso kramst du jetzt haufenweise alte Diskussionen raus?
Weil mir nach der Suche nach dem Thema Drehgeber dieser thread vorgeschlagen wurde. Darf man diese Frage nicht stellen?
Harald E. schrieb: > wenn man zu langsam daran dreht. > > Wieso das? Weil dann keine Spannung in den Spulen induziert wird. Allerdings wird man das bei empfindlichen Komparatoren in der Auswertung so gut wie nie hinkriegen.
Harald E. schrieb: > Weil mir nach der Suche nach dem Thema Drehgeber dieser thread > vorgeschlagen wurde. Darf man diese Frage nicht stellen? Fragen zu stellen ist allemal erlaubt. Allerdings ist die Suchfunktion in diesem Forum etwas eigenwillig, so daß man recht oft - eigentlich fast immer - die am wenigsten passenden Beiträge vorrangig präsentiert bekommt. Muß man sich halt dran gewöhnen und spätestens vor dem Abschicken einer Antwort auf das Datum schauen. Ansonsten ärgert es mich immer wieder, daß so unsäglich viele Leute es nicht schaffen, einen Drehgeber anzuschließen und auszuwerten. Aber benutzen wollen. Klingt etwa so: "ich kann zwar nicht autofahren, aber ich will mit meinem Bettchen zum Mond fliegen - und zuvor etwas dazu zu lernen ist mir zu mühsam". Deshalb verlegen die sich auf das Benutzen von fertigem Quellcode ohne ihn zu verstehen. Sowas ist eine Geisteshaltung, die mir gegen den Strich geht. Und das regt mich auf. W.S.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.