Hallo Ihr! Wer seinen Dreh-Encoder (Rotary-Encoder, Drehimpulsgeber oder wie auch immer) abfragen und softwaretechnisch entprellen möchte, dabei aus Performance-Gründen ohne Verzögerungsschleifen oder Timern arbeiten muß und zusätzlich noch die zwei externen Interrupts frei hat, für den ist mein Code genau das richtige. Das Ganze basiert auf einem Automaten mit 2 Zuständen und benötigt so auch lediglich 1 Bit Speicherplatz. Funktioniert bei mir perfekt. Schauts euch mal an. Verbesserungsvorschläge und Danksagungen herzlichen Willkommen! ;) ciao Christian
Hallo Christian, hast Du auch eine entsprechende Lösung in C? Das wäre mir sehr hilfreich. Gruß Winfried
Hi Winfried, nein leider nicht... alles nur in Assembler bei mir :) ... du solltest aber anhand der Kommentare ziemlich schnell C-Code daraus machen können... ansonsten als Inline-ASM reinnehmen... aber was viel schlimmer ist; ich sehe gerade, daß der Code einen Fehler hat: in der siebten Zeile nach "; INT1 (B)" (also Zeile 103)steht "rjmp e_int1"... das ist natürlich falsch, weil er sonst immer wieder nach oben springt... richtig ist "rjmp e_int11"... sorry dafür, muss beim Umbenennen der Sprungmarken passiert sein! anbei noch einmal die korrigierte Fassung... ciao Christian
Es ist ja schön jede Zeile beschrieben, was da gemacht wird, nur warum es gemacht wird, ist mir nicht klar ? Es wäre also schön, wenn Du das Prinzip beschreiben könntest, wie Dein Programm arbeitet. Dann könnte man es auch in C umschreiben. Nur jede Instruktion stur nach C zu konvertieren, ohne es zu verstehen, dürfte viel zu fehlerträchtig sein und daher kaum erfolgreich sein. Allgemein ist das Triggern auf beide Flanken nicht einfach. Man sollte immer erst den Pegel testen, ob auch wirklich die gewollte Flanke einen Interrupt ausgelöst hat oder es nur eine Störung war. Dann muß man nach dem Umschalten wieder testen, ob nicht vielleicht gerade wärend des Umschaltens eine Flanke aufgetreten ist. Peter
Ok, ich werde mal versuchen, es zu erklären... also das ganze basiert wie gesagt auf einem Automaten, den ich anhand der Pegel-Wechsel beim Drehen des Encoders entworfen habe. Mein ursprünglicher Automat hatte glaube ich 9 Zustände, die ich auf lediglich 2 minimieren konnte (fragt bitte nicht, wie der Automat einmal aussah! :))... den aktuellen Automaten findet ihr im Anhang... für diejenigen unter euch, die mit Automatentheorie nicht so vertraut sind: Die Kreise sind die Zustände (mit den entsprechenden Namen drin (hier binär)), die Pfeile sind die Übergänge von einem Zustand in den anderen und an den Pfeilen stehen die möglichen Eingaben und die entsprechenden Ausgaben, die den Automat veranlassen den Zustand zu wechseln (in der Form "Eingabe, Ausgabe(n)")... ich habe die Eingaben in folgender Form geschrieben: A und B stehen für die entsprechenden Pins des Encoders von denen High oder Low kommt (bzw INT0 und INT1 am controller)... die Zahl in der Klammer gibt an, ob der aktuelle Pegel Low (0) oder High (1) ist... so bedeutet "A fällt (1), Minus" am Pfeil von Zustand0 nach Zustand1 also, daß der Zustand von 0 nach 1 gewechselt wird, wenn am Pin A des Encoders eine fallende Flanke erzeugt wird, der Pegel aber trotzdem High ist (wenn z.B. wieder zurückgeprellt wurde o.Ä.) und das als Ausgabe dann ein Minus erfolgt (sprich: Encoder wurde nach Links gedreht) (soviel zu Peters Hinweis, auf die gewollte Flanke zu testen)... das "Steigend" und "Fallend" in der Ausgabe bedeutet, daß ab sofort der entsprechende Eingang (INT0 (A) oder INT1 (B) vom controller) auf die steigende oder fallende Flanke reagieren soll... Man sollte zum besseren Verständnis sich das Datenblatt eines Encoders (bzw dessen Ausgangssignale) anschauen und dann einfach mal Schritt für Schritt durchgehen... Beispiel: nehmen wir an, der Encoder steht ursprünglich in einer Rast-Position, in der A = Low (0) sowie B = Low (0)... dann wird durch die Initialisierung zunächst einmal der richtige Start-Zustand bestimmt (hier Zustand 0) und INT0 und INT1 sollen auf die steigende Flanke reagieren (denn wenn beide LOW sind wird ja wohl beim nächsten Bewegen des Encoders ne steigende Flanke kommen)... wird der Encoder jetzt nach Rechts (im Uhrzeigersinn) gedreht, wird zunächst auf INT0 (A) eine steigende Flanke kommen und dann auf INT1 (B)... im Automaten sieht das dann so aus: "A steigt (1)" führt von Zustand 0 in den Zustand 1 und es wird INT0 ab jetzt auf die fallende Flanke reagieren, anschließend wird mit der Eingabe "B steigt (1)" im Zustand 1 gekreist und dabei B (INT1) auf die fallende Flanke geschaltet und Plus "ausgegeben" (bzw gemacht halt)... auch das Prellen des Encoders wird mit der Automaten-Logik aufgefangen... einfach mal ausprobieren! Der Code ist also nix anderes als der AVR-Assembler gerecht gemachte Automat... noch mal zu Peter; die Geschichte, daß man testen sollte ob während des Umschaltens eine Flanke auftritt habe ich ehrlich gesagt nicht bedacht... ich denke aber mal, daß das so selten auftritt, daß man es hier vernachlässigen kann... wenn noch Fragen sind, dann los... ciao Christian
Ist schon eine Menge Kode nur fuers Ablesen eines Encoders. Ich habe meine Kode leider nicht so schnell dabei, aber habe andere Loesung gewaehlt. Nennen wir die Encoder Signale Xa und Xb Xa wird auf Int0 UND Int1 angeboten. Int0 wird zur Erkennung aufgehenden Flanken konfiguriert. Int1 wird fuer abgehende Flanken verwendet. Xb wird angeboten ueber ums eben welche andere IO pin. Nun teste ich bei Interrupthaendler Int0 und Int1 der Wert von Xb. Int1: Xb == 1 ? -> Positive Drehung sonst Negative Drehung Int0: Xb == 0 ? -> Positive Drehung sonst Negative Drehung Kann man in etwa 10 ASM commands ausschreiben. Nachteil ist das ich nicht die ganze Resolution vom Encoder verwende.
Das ganze in C findest du im Code für den h-mpeg mp3player... http://www.h-mpeg.de und dann auf Downloads.
Hallo, wenn man die Layouts und die Schaltpläne, die auf der Seite http://www.h-mpeg.de öffnen mit einer korrekt lizensierten Eagle-Version öffnen will, dann gibt es den berühmten Load-Error, der auf die Erstellung dieser Dateien mit einer Raubkopie hinweisen!!! Werner
Hallo, bin grad auf diesen Code gestoßen. Hätte da mal eine Frage dazu: Der Automat ist im Zustand 0 und es kommt eine steigende Flanke an A. Dann wechselt der Automat in den Zustand 1, aber woher weis der Automat welche Aktion er bei steigender Flanke ausführen muss? Es gibt zwei : 1. im Pfeil von 0 nach 1 2. im Pfeil von 0 nach 0 oder muss er beide abarbeiten? Das gleiche Problem ist wenn der Automat jetzt mit steigender Flanke in Zustand 1 wechselt und der Kontakt prellt(also eine negative Flanke erzeugt) Wechselt der Automat dan wieder in Zustand 0, da es ja am Pfeil von 1 nach 0 eine Anweisung gibt, das bei fallender Flanke wieder nach 0 gewechselt werden soll? Wäre schön wenn mir das jemande erklären könnte, da ich mit dieser Darstellung noch keine Erfahrung gemacht habe während meiner 2jährigen Lehrzeit. mfg Benedikt
Hallo, kann mir den keiner meine Fragen beantworten? mfg Benedikt
hammer_c wrote:
> Ok, ich werde mal versuchen, es zu erklären...
Mal ne ganz andere Frage: mit was ist denn dieser hübsche Automat
gezeichnet? Ist das Visio?
Danke, Grüße, holli
@ Benedikt Lippert (Gast) >Der Automat ist im Zustand 0 und es kommt eine steigende Flanke an A. >Dann wechselt der Automat in den Zustand 1, aber woher weis der Automat >welche Aktion er bei steigender Flanke ausführen muss? Dieser Automat mit nur zwei Zuständen ist sinnlos. Ein Drehgeber hat vier Codes, Gray-Codes. Beim Übergang zwischen benachbarten Codes wir der Pulszähler incementiert oder dekrementiert. Beim Übergang zwischen nichtbenachbarten Codes muss ein Fehler signalisiert werden. MFG Falk
Wie oft denn noch?! Encoder an zwei Interruptleitungen ist SCHWACHSINN. Und dieses "Wenn-Leitung-A-sich-ändert-dann-werte-Leitung-B-aus" ist noch größerer Schwachsinn. Wenn man doch sowieso schon nen Timer laufen hat, dürfte es doch möglich sein, da noch ne schnucklige kleine Entprellroutine mitlaufen zu lassen...
... habe das mit den beiden Interrupts und der Auswertung der Drehgeber mit c getestet (imagecraft ICC) und es klappt wirklich wunderbar: ############################################################## ############################################################## ############################################################## // PHASEA u -B sind die beiden Encoder Eingänge #define PHASEA (PIND & 1<<PIND1) // PIND.1 ist #define PHASEB (PIND & 1<<PIND2) // PIND.2 ist // phasen-check: bestimmung ob interrupt mit fallender oder steigend. //flanke. Hier verwende ich interrupt1 auch alf fallende Flanke für den //Taster void check_phase(void) { switch (PHASEA+PHASEB) { case 0: EICRA = 0x3E; break; //Int0:Fall/Int1:Rise/Int2:Rise/ case 2: EICRA = 0x3A; break; //Int0:Fall/Int1:Fall/Int2:Rise/ case 4: EICRA = 0x2E; break; //Int0:Fall/Int1:Rise/Int2:Fall/ case 6: EICRA = 0x2A; break; //Int0:Fall/Int1:Fall/Int2:Fall/ } } // Interrupt-Routine 1 #pragma interrupt_handler int1_isr:iv_INT1 void int1_isr(void) { //external interupt on INT1 switch (PHASEA+PHASEB) { case 0: if (EICRA==0x3E | EICRA==0x3A) count++; else count--; break; case 6: if (EICRA==0x3E | EICRA==0x3A) count--; else count++; break; } check_phase(); } // Interrupt-Routine 1 #pragma interrupt_handler int2_isr:iv_INT2 void int2_isr(void) { //external interupt on INT2 switch (PHASEA+PHASEB) { case 0: if (EICRA==0x3E | EICRA==0x2E) count--; else count++; break; case 6: if (EICRA==0x3E | EICRA==0x2E) count++; else count--; break; } check_phase(); } //main void main(void) { init_devices(); check_phase(); while (1) { printf(count); } } ############################################################## ############################################################## ############################################################## PS: Wenn einer eine bessere Lösung mit einem Interrupt hat bitte!
abdal wrote: > PS: Wenn einer eine bessere Lösung mit einem Interrupt hat bitte! Ich denke, die ist ganz ordentlich: http://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C Ist vor allem universell für alle Encodertypen, d.h. für nichtrastende (jeder Phasenwechsel) oder für rastende mit 2 bzw. 4 Phasenwechseln. Peter
Ja, und die ist sogar ohne Interrupts, was ein Vorteil und kein Nachteil ist.
Peter Dannegger schrieb: > abdal wrote: > >> PS: Wenn einer eine bessere Lösung mit einem Interrupt hat bitte! > > Ich denke, die ist ganz ordentlich: > > http://www.mikrocontroller.net/articles/Drehgeber#... > > Ist vor allem universell für alle Encodertypen, d.h. für nichtrastende > (jeder Phasenwechsel) oder für rastende mit 2 bzw. 4 Phasenwechseln. > > > Peter Hi, der Code in Bascom, wäre für Viele hier im Forum auch sehr vorteilhaft. Wäre nett, wenn das bitte einer schreiben könnte. Vielen Dank Andreas
Andreas Hickmann schrieb: > Hi, > > der Code in Bascom, wäre für Viele hier im Forum auch sehr vorteilhaft. > Wäre nett, wenn das bitte einer schreiben könnte. > > Vielen Dank Andreas Du hast dich doch gerade freiwillig gemeldet, oder? :-) Meine Wohnung müsste auch mal wieder geputzt werden, wäre nett, wenn hier mal jemand vorbei kommen könnte ...
Frank O. schrieb: > Meine Wohnung müsste auch mal wieder geputzt werden, wäre nett, wenn > hier mal jemand vorbei kommen könnte ... Es ist wirklich schade, dass hier im Forum oft nur Mist geschrieben wird. Gruß Andreas
Andreas Hickmann schrieb: > Frank O. schrieb: > >> Meine Wohnung müsste auch mal wieder geputzt werden, wäre nett, wenn >> hier mal jemand vorbei kommen könnte ... > > Es ist wirklich schade, dass hier im Forum oft nur Mist geschrieben > wird. > > Gruß Andreas Andreas, bleib mal locker! Verstehst du keinen Spaß? Ich übersetze mal deinen Satz für mein Verständnis: "Also, ich möchte das in Bascom haben. Haut mal rein und programmiert mir das!" Das ich dann spaßeshalber auch "meine Wünsche" hier anbringe, das solltest du mal als das nehmen was es ist, es war lediglich ein Spaß. Du forderst hier die Leute auf für dich etwas zu programmieren. Weil du es nicht kannst oder einfach keinen Bock hast. Helfen wird dir sicher immer jemand, wenn du hängst, aber diese Aufforderung muss ja quasi einen Scherz nach sich ziehen. Es ist wirklich schade, dass du so wenig Humor hast.
Andreas Hickmann schrieb: > Es ist wirklich schade, dass hier im Forum oft nur Mist geschrieben > wird. Und Bascom.
Andreas Hickmann schrieb: > Frank O. schrieb: > >> Meine Wohnung müsste auch mal wieder geputzt werden, wäre nett, wenn >> hier mal jemand vorbei kommen könnte ... > > Es ist wirklich schade, dass hier im Forum oft nur Mist geschrieben > wird. > > Gruß Andreas Andreas, bleib mal locker! Verstehst du keinen Spaß? Ich übersetze mal deinen Satz für mein Verständnis: "Also, ich möchte das in Bascom haben. Haut mal rein und programmiert mir das!" Das ich dann spaßeshalber auch "meine Wünsche" hier anbringe, das solltest du mal als das nehmen was es ist, es war lediglich ein Spaß. Du forderst hier die Leute auf für dich etwas zu programmieren. Weil du es nicht kannst oder einfach keinen Bock hast. Helfen wird dir sicher immer jemand, wenn du hängst, aber diese Aufforderung muss ja quasi einen Scherz nach sich ziehen. Es ist wirklich schade, dass du so wenig Humor hast.
In Bascom ist das mit ein paar Zeilen zu machen..... erst mal brauchst Du mindestens einen Interrupt mir reicht einer, Du kannst natürlich auch zwei nehmen, wenn die auflösung feiner sein soll, aber je nach Chip kann man ja die Änderung auswerten und nicht nur up oder down in diesem Fall ein Atmega48: config Pind2 = Input config Pind3 = Input Config Int0 = Change Enable interrupts Enable Int0 On Int0 Updn Updn: If Pind2 = Pind.3 then incr X If Pind2 <> Pind.3 then decr X return .......wobei mit X die zu ändernde Variable gemeint ist. Die Werte müssen natürlich noch begrenzt werden, aber das bleibt jedem selber überlassen...... Wichtig ist das Prinzip, die Flanke des einen Kanals auszuwerten und dann zu schauen ob der andere Kanal gleich oder anders ist. If Pind2 = Pind.3 then incr X else decr X müsste auch gehen man kann statt mit Interrupts notfalls auch mit Debounce arbeiten, aber da sollte die Laufzeit des Hauptprogramms sehr kurz sein, oder man hüpft alle paar Zeilen ins Unterprogramm mit der Auswertung sonst hakt das fürchterlich.Nur in Notfällen sinnvoll! mfG Franz
Hi Fanz, endlich mal eine sinnvolle Antwort. Vielen Dank. Werde ich gleich mal testen. Gruß Andreas
> In Bascom ist das mit ein paar Zeilen zu machen..... Wie schrieb schon Sven P. 2008 : "Wie oft denn noch?! Encoder an zwei Interruptleitungen ist SCHWACHSINN. Und dieses "Wenn-Leitung-A-sich-ändert-dann-werte-Leitung-B-aus" ist noch größerer Schwachsinn. " Blöd wenn man den Thread nicht bis zu http://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C gelesen hat.
Ich habe nicht behauptet, dass das die beste und einzige Möglichkeit ist einen Drehgeber auszuwerten, aber das ist in Bascom eine sehr interessante Variante und wenn der Encoder ein bisschen entprellt ist, (10k Pull-Up und 100nF nach Gnd) dann reicht das allemal um mit einem kleinen Drehencoder mit Taster ein Menue zu steuern rauf, runter, weiter..... Es gibt Fälle, da hat man Timer frei, aber keine Interrupts ich hatte aber das Problem, keine Timer sondern die Interrupts frei gehabt zu haben, und da hat sich das angeboten. ....mir ist auch der "ENCODER"-Befehl in Bascom bekannt, aber der ist auch nicht immer die erste Wahl, wenn der Geber ständig abgefragt werden soll, unabhängig davon,was das Programm gerade macht. und auch wenn es um Höchstgeschwindigkeit geht, dann ist die Interrupt-Variante die schnellste, weil da die Abtastung immer absoluten Vorrang hat. Versuche mal den Wert eines hochauflösenden Inkrementalgebers mit einem Atmega und Bascom auf ein Display zu schreiben.... Wenn man das Signal nicht vorher per Hardware in Takt und Richtung aufbereitet was man ja in solch einem Fall meist vermeiden möchte, dann ist die Interruptmethode die einzig brauchbare, weil sich sogar das Schreiben ins Display dem Interrupt unterordnet. Das funktioniert bis zu einigen Kilohertz.Der einzige echte Nachteil der Interrupt-Methode ist das Zappeln, das auftreten kann, wenn der Kanal des Gebers der den Interrupt auslöst zappelt, aber das ist dann kein Fehler der Auswertemethode sondern eine Fehlfunktion des Gebers. Also lieber MaWin, hier hat jemand,danach gefragt, ob nicht irgendwer dieses Verfahren in Bascom hätte.... Und weil ich genau dieses zufällig sowieso irgendwo in einigen meiner Programme genau so drin habe, und es ganz hervorragend funktioniert (und ich auch schon andere getestet habe) habe ich es hier in diesem kürzlich wieder ausgegrabenen Thread gepostet. Wenn Du also dieses oder andere Programme oder Verfahren aus irgend einem Grund der ja durchaus berechtigt sein kann, nicht gut findest, dann antworte bitte sachlich und korrekt oder machs halt einfach besser...... Aber hier von Schwachsinn oder noch größerem Schwachsinn zu reden oder zu zitieren und von blöd zu reden schiesst doch ein bisschen übers Ziel hinaus! Es kommt immer auf den jeweiligen Fall an, wie die optimale Lösung aussieht. mfG Franz
Vehikelfranz schrieb: > Es kommt immer auf den jeweiligen Fall an, wie die optimale > Lösung aussieht. sehr, sehr wenig. ein quadratur-signal ist ein quadratur-signal. > dann antworte bitte sachlich und korrekt > oder machs halt einfach besser...... genau das wurde hier im thread schon mehrfach getan. wer halt zu faul zum lesen ist, der muss sich dann sowas anhören. nochmal vorkauen, was an anderen stellen schon zig-fach geschrieben wurde, ist nach der grundschule einfach nur unsitte. zu der stufe solltest du dann mal kommen.
Hallo, da ich aus meinen alten Geräten einige Drehgeber gewonnen habe, wollte ich den Drehgeber an einen Atmel anschliessen (habe schon ziemlich lange mich mit denen beschäftigt ...) und erstmal die hier veröffentlichte Software getestet ... kein Erfolg ... leider... Leute schreiben z.B. sie verwenden bestimmten Proz. im Programm stehen aber verschiedene Parameter, die nicht dazu passen ... Ich habe also mich selbst dran gemacht und in C ein kurzes Prog geschrieben. Es funktioniert tadellos ... Für die Entprellung der beiden Drehgeberanschlüsse habe ich 100 nF Kerko und 4.7 k Pull-up verwendet. Viel Spaß damit ...
Richard S. schrieb: > und erstmal die hier > veröffentlichte Software getestet ... kein Erfolg Vielleicht hättest du vorher lesen sollen, wie man es richtig macht, was auch der hammer_c nicht beachtet hat: https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 Richard S. schrieb: > Für die Entprellung der beiden Drehgeberanschlüsse habe ich 100 nF Kerko > und 4.7 k Pull-up verwendet. Da du NATÜRLICH keinen Schaltplan angegeben hast, kann man nur vermuten, dass 4k7 als pull up und 100nF über den Encoderkontalten sitzen: das entladen der 100nF schadet den Encoderkontakten, die Funken rauen die Kontakte auf, das prellen nimmt zu, bis es die Encoderauswertung stört. Da du Interrupts auf Flankenwechsel nutzt, dann aber den aktuellen Encoderzustand vom Port einliest (der schon wieder anders sein kann als der zum Flankenwechsel führte), stört Prellen deine Software sehr stark.
Beitrag #6785336 wurde vom Autor gelöscht.
MaWin schrieb: > Da du NATÜRLICH keinen Schaltplan angegeben hast... musste ich nicht, da der Satz von mir ziemlich klar ist ...:) MaWin schrieb: > das > entladen der 100nF schadet den Encoderkontakten, die Funken.... tja, vielleicht, wenn man den Drehgeber mit Motor 24 Std ein paar Jahren betreiben würde bei diesen Entladeströmen...:)... Aber du hast mich doch irgendwie motiviert und habe beschlossen mehr Zeit der Aufgabe zu widmen und habe das Prog vom Peter doch an meinen ATmega168 angepasst und als Anzeige eben mein LCD-Display verwendet... Es funktioniert tatsächlich einwandfrei ohne Entprellungsmaßnahmen ...
Richard S. schrieb: > Es funktioniert tatsächlich einwandfrei ohne Entprellungsmaßnahmen ... Kein Wunder, macht er das doch bereits in Software. ;-) Versuche mal, Peda's Code zu verstehen.
MaWin schrieb: > das > entladen der 100nF schadet den Encoderkontakten, die Funken rauen die > Kontakte auf, das prellen nimmt zu, bis es die Encoderauswertung stört. Frage dazu: oxidieren die Kontakte nicht ohne Strom? Z.B. bei Relaiskontakten ist ein Minimum an Strom wünschenswert für die Selbstreinigung.
Ozvald K. schrieb: > oxidieren die Kontakte nicht ohne Strom Ja, Taster brauchen einen Mindeststrom, der wäre bei 4k7 um 1mA, sollte reichen. Die meisten Encoder werden aber keine Zaster sondern schleifende Kontakte haben, die reinigen sich selbst (und nutzen sich dabei ab, halt billig). Eine RC Kombination nach dem Kontakt ist trotzdem nützlich da eben jene schleifenden Kontakte während der Bewegung ständig kurze Unterbrechungen haben (nicht nur Prellen an den Übergängen, sondern die ganze Kontaktfläche lang) die die Auswertung stören und durch eine RC Kombi unterdrückt werden. Aber die sollte halt nicht die Kontakte durch zu hohen Kondensatorentladestrom schädigen.
MaWin schrieb: > Eine RC Kombination nach dem Kontakt ist trotzdem nützlich da eben jene > schleifenden Kontakte während der Bewegung ständig kurze Unterbrechungen > haben (nicht nur Prellen an den Übergängen, sondern die ganze > Kontaktfläche lang) die die Auswertung stören und durch eine RC Kombi > unterdrückt werden. Alle mir bekannte Encoder (selbst die billigsten) haben mindestens zwei Kontaktzungen pro Kontakt (manche sogar drei). Die Wahrscheinlichkeit, dass während der Bewegung beide Kontaktzungen gleichzeitig springen, ist sehr gering. Noch geringer ist die Wahrscheinlichkeit, dass dieses Ereignis zeitlich mit der zyklischen Abtastung durch die Software zusammenfällt. Nur in diesem extrem unwahrscheinlichen Fall wird der Zählerstand kurzzeitig um 1 Inkrement daneben liegen, was aber – weil der Encoder sowieso in Bewegung ist – nicht auffällt und schon im nächstens Abtastzyklus wieder korrigiert wird.
Yalu X. schrieb: > Die Wahrscheinlichkeit, > dass während der Bewegung beide Kontaktzungen gleichzeitig springen, ist > sehr gering. Sie steigt mit dem Alter, also letztlich eine Frage wann die Obsoleszenz eintreten soll.
Yalu X. schrieb: > Die Wahrscheinlichkeit, > dass während der Bewegung beide Kontaktzungen gleichzeitig springen, ist > sehr gering. Aber eben nicht Null. Und da man so etwas für den worst case auslegt macht man halt eine Entprellung. Bei einem elektronischen Poti mag das egal sein, aber nicht bei einer Positionsbestimmung. MaWin schrieb: > die die Auswertung stören und durch eine RC Kombi > unterdrückt werden. So eben nicht. SW Entprellung ist das Stichwort. Peda macht es genau richtig. RC zusätzlich schadet auch nicht unbedingt, habe ich aber noch nie gemacht.
Ich habe mein Prog mit den zwei Interrupts noch einmal genauer angeschaut und eben beobachtet, dass manchmal eine weitere Rastung nicht gezählt wird ... es ist nicht präzise genug die Flankenauswertung. Der Peter in seinm Prog macht die Auswertung der Zustände (z.B.: rechts - 01|00|10|11 und links - 10|00|01|11 ) an den Drehgeberleitungen und nicht die Flanken... Peter, vielen Dank an dieser Stelle ! ...
:
Bearbeitet durch User
Andreas B. schrieb: > Yalu X. schrieb: >> Die Wahrscheinlichkeit, dass während der Bewegung beide Kontaktzungen >> gleichzeitig springen, ist sehr gering. > > Aber eben nicht Null. Nichts ist absolut perfekt :) > Und da man so etwas für den worst case auslegt macht man halt eine > Entprellung. Man kann das machen, macht es i.Allg. aber nicht. Eine Entprellung mittels Tiefpass und Schmitt-Trigger (oder mittels vergleichbarer Softwaremethoden) reduziert zwar den Effekt des Prellens, gleichzeitig aber auch die maximale Drehzahl, bei der die Auswertung noch nicht ins Stolpern kommt. > SW Entprellung ist das Stichwort. Peda macht es genau richtig. Ja Peter macht es richtig, aber ganz ohne Entprellung. Er wendet die klassische Methode an (periodische Abtastung und Auswertung der Zustandsänderungen). Ein Glitch in einem der beiden Encoder-Signale, der mit einem Abtastzeitpunkt zusammenfällt, führt auch bei ihm zu einer temporären Änderung des Zählerstands um ±1. Das wird aber gemeinhin in Kauf genommen, da dieser Fehler - bei einem intakten elektromechanischen Encoder äußerst selten und bei einem optoelektronischen überhaupt nicht auftritt, - temporärer Natur ist (er wird schon im nächsten Abtastzyklus korrigiert), - nicht akkumuliert wird und - dessen Beseitigung mittels HW-odet SW-Entprellung andere Nachtteile mit sich bringen würde (s.o.).
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Ja Peter macht es richtig, aber ganz ohne Entprellung. Er wendet die > klassische Methode an (periodische Abtastung und Auswertung der > Zustandsänderungen). Stimmt, gerade nochmal reingeschaut. Ich hatte irgendwie im Kopf daß er das mehrmals abtastet.
Yalu X. schrieb: > Ein Glitch in einem der beiden Encoder-Signale, der > mit einem Abtastzeitpunkt zusammenfällt, führt auch bei ihm zu einer > temporären Änderung des Zählerstands um ±1. Das wird aber gemeinhin in > Kauf genommen, da dieser Fehler Woher weißt du, dass das ein Fehler ist. Vielleicht steht der Encoder wirklich genau auf der Grenze, so dass eine 50%-Wahrscheinlichkeit für jeden der beiden Zustände die Position sauber beschreibt. Die Schwankung um ±1 (eigentlich ±1/2?) fällt dann unter Quantisierungsrauschen. Einziges Mittel dagegen ist eine Hysterese, gesteuert durch die Auswertung der Richtungsumkehr.
Wolfgang schrieb: > Einziges Mittel dagegen ist eine Hysterese Nope. Einziges Mittel dagegen ist Intelligenz, um die Auswertung richtig zu machen, und nicht auf Flankenwechseln die Interrupts erzeugen aufzusetzen. Der TO hat es inzwischen gelernt....
Andreas B. schrieb: > Yalu X. schrieb: >> Ja Peter macht es richtig, > > Stimmt wer seine Tastenentprellung kennt kommt mit der Drehencoderroutine sofort klar, ich hatte nur den Timer IRQ auf 1ms gesetzt, wer unbedingt schneller drehen will bitte schön, geht auch noch kürzer. Man muss nur etwas spielen mit den Routinen 1-fach, 2-fach, bei mir war es ein 4-fach Encoder.
Werner Schwarz schrieb: > Hallo, > wenn man die Layouts und die Schaltpläne, die auf der Seite > http://www.h-mpeg.de öffnen mit einer korrekt lizensierten Eagle-Version > öffnen will, dann gibt es den berühmten > Load-Error, der auf die Erstellung dieser Dateien mit einer Raubkopie > hinweisen!!! > Werner Wahnsinn !!!! Das gehört gemeldet!
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.