Hi, Ich hab aus einer alten PC-Maus den Drehimpulgeber ausgebaut. (Mausrad) Diesen hab ich jetzt an meinen µC (MEGA16) angeschlossen und Programm dazu geschrieben. vorerst sollte eine Variable in/decrementiert werden. Dazu werte ich aus, welcher der Beiden Anschlüsse zuerst seinen Wert ändert. prinzipiell funktioniert das Programm. Öfters (besonders bei einer der beiden Richtungen) funktioniert das aber nicht. Da wird der Zähler immer mal wieder in die falsche richtung gezählt (zb. 4 5 6 5 4 5 statt 4 5 6 7). An was kann das liegen? Code im Anhang. (MEGA 16 @16Mhz) Ich weiß, Code ist schlecht, wenn noch andere Sachen gemacht werden sollen (böse Warteschleifen) mfg J.K
Ohne mir den Code anzusehen: Passiert das "In die Falsche Richtung zählen" wenn du schnell drehst? Und geht alles wenn du langsam drehst? Dann ist die Abtastung zu langsam und kommt mit der Frequenz der Eingangssignale nicht klar. Mfg
Das was Christian geschrieben hat wäre auch meine erste Idee gewesen: zu langsame Abtastung. Das Problem hatte ich bei meinem Drehencoder auch, bei zu langsamer Abtastung und einer zu hohen Drehgeschwindigkeit des Drehknopfs hat das Modul falsch abgetastet. Stichwort: http://de.wikipedia.org/wiki/Alias-Effekt Häufiger Fehler, über den man gerade in der Signalverarbeitung häufig stolpert. Ich habe so gelöst: Beim Drehen entsteht ein "puls" (low-high z.b.) auf einer Spur (A oder B).. In diese Spur taste ich 4 mal (!) mit einer Frequenz von 1 kHz. (Realisiert mit dem RTC - Real Time Counter) An den Spuren entsteht ein so genannter Gray-Code. Die Routine wertet nun die Signal aus und puffert diese Werte. Wird nun 4 mal ein "Links-Indikator" detektiert meldet meine Routine einen "Links-Impuls".... das funktioniert bei mir einwandfrei! Auch bei seeeeeeehr langsamen Drehen (um der Frage gleich vorzubeugen ;-) )... meine Routine berücksichtigt folgende Fälle: "Links Indikator" "Wiederholungs-Indikator" damit ist der Fall des langsamen Drehens abgedeckt "Rechts Indikator" "Fehler Indikator" In deinem Fall wäre z.B. ein Fehler-Indikator bei mir gemeldet worden.. (unzulässige Code-Folge) meine Routine setzt daraufhin die Indikator-Zähler zurück und start neue Zähl-Periode... damit nicht sowas wie bei dir passiert: 4, 5, 6, 5, 6..... Die Routine hat eine Ausführungsdauer von 34 Mikrosekunden... also eine Auslastung unter 4 %... das is noch ok! Wenn du Code oder sonst was willst! Einfach melden! :-) Gruß Sebastian
Der Ansatz ist falsch! Und die verschachtelten Warteschleifen sind auch nicht grad gut. Beitrag "Drehgeber auslesen"
PS: Die Routine ist nur so "langsam", weil ich noch "schnelles Drehen" berücksichtige... also Rückgabewert gibt meine Routine noch einen Multiplikations-Faktor... x1, x10, x100.... Will man z.b. über ein Display einen Anlog Wert hochdrehen... dann dreht man sich bei einer Auflösung von 0.001 V einen Wolf, wenn man von 1 V auf 5 V will... die routine detektiert "schnelles" drehen... setzt einen multiplaktions-indikator.. und mein auswertendes modul kann dann den analog-wert mal schnell um faktor 10 oder 100 erhöhen.. da es "merkt", dass der benutzer schnell mal den wert hoch schrauben will... das ganze funktioniert einwandfrei! auch normale einstellungen +/- 1 sind problemlos möglich ;-) Da die schwellen (nach tests) optimal gewählt wurden...
ohje... so viel Diskussion um so ein einfaches Thema ;-) einfach: - schnell genug abtasten - spuren richtig umcodieren - werte puffern (letzter Wert, neuester Wert) - auswerten über ne 4x4 Look-Up-Table - vielleicht noch geschwindigkeitsänderungen detektieren... und aus die maus ;-) (Wird aber auch in teuren Geräten oft genug noch falsch gemacht....! Was ich da schon an Routinen "gesehen" habe... da kommt einem das kalten GRauen...)
Mehr Infos siehe Dateianhang... das ist ne ganz gute Erklärung zu dem ganzen Thema! nen guuden!
@ Sebastian B. (Firma cD) (mircobolle)
>Dateianhang: MasterThesis_auszug.pdf (121,4 KB, 2 Downloads)
Seite 2
"Das ermöglicht die asynchrone Abtastung, ohne mehr als einen Schritt
vom wahren Ergebnis entfernt zu sein, weil maximal ein Bit falsch
erfasst wird (weitere Informationen zu diesem Thema unter: [Mik08])."
Kommt mir verdammt bekannt vor der Text ;-)
Muss sowas aber in einer offiziellen Diplomarbeit, ähhh Meisterthese in
Gänsefüsschen eindeutig als Zitat gekennzeichnet werden?
MfG
Falk
MfG
Falk
@Falk Zitat-Hinweise sind natürlich Sache des Professors (wie er es gern mag). Aber [Mik08] verweist ja auf den Link, wo die Text Stelle zu finden ist ;-) Muss hier allgemein mal ein großes Lob an das Forum und besonders das Wiki aussprechen. Die Beiträge sind wirklich zum einen verständlich und zum anderen auch noch inhaltlich fundiert geschrieben. Großer Respekt ;-) Leider, sind bei den Beiträgen oft keine Autoren genannt, so dass man diese richtig im Literaturverzeichnis zitieren kann. Somit steht als "Autor" nur:http://www.mikrocontroller.net ich hoffe damit fühlt sich niemand beleidigt ;-) oder benachteiligt. Gruß Sebastian
[Mik08]............... Mikrocontroller.net: Drehgeber URL: [http://www.mikrocontroller.net/articles/Drehgeber] Stand:18.08.2008 so sieht der Literaturhinweis aus ;-)
Danke für die Antworten! Matthias Lipinsky wrote: > Der Ansatz ist falsch! Und die verschachtelten Warteschleifen sind auch > nicht grad gut. > > Beitrag "Drehgeber auslesen" warum? mein Drehencoder ist im Prinzip der wie im Wikiartikel >http://www.mikrocontroller.net/articles/Drehgeber dh. er rastet bei 00 und 11 ein. wie im wikiartikel zu erkennen ändert sich bei Drehrichtung nachts rechts die Spur A zuerst, links Spur B Die Abtastfrequenz ist sichter hoch genug. Der µC ist mit 16Mhz getaktet und macht die ganze Zeit nichts anderes(siehe Code)! Er geht nur in die Warteschleife wenn eine Weiterdrehung erkannt wurde (um die Änderung der 2. Spur zu ignorieren). Das Phänomen tritt bei langsamer und schneller Drehung gleichermaßen auf.
Servus J.K. >mein Drehencoder ist im Prinzip der wie im Wikiartikel >>http://www.mikrocontroller.net/articles/Drehgeber >dh. er rastet bei 00 und 11 ein. Was meinst du mit er rastet ein? Also meiner Meinung nach wird bei einer "Einrastung" (z.B. 24 Raster / 360 Grad)... ein Impuls (wie im Artikel erzeugt). Jede Spur erzeugt so einen Impuls.. 90 GRad Phasenversetzt. Je nach dem wie die Spuren zueinander stehen lässt sich dann die Drehrichtung ermitteln.. (GRay-Code).. Ich hab mir deinen Code jetzt nicht angeschaut. Nochmal zur Klarstellung? Tastest du ab, oder arbeitest du mit Flanken-Interrupts? >Die Abtastfrequenz ist sichter hoch genug. Der µC ist mit 16Mhz getaktet >und macht die ganze Zeit nichts anderes(siehe Code)! Er geht nur in die >Warteschleife wenn eine Weiterdrehung erkannt wurde (um die Änderung der >2. Spur zu ignorieren). 62,5 Nanosekunden... wäre dein Takt.. bei 16MHz Abtastfrequenz.. in 62,5 Nanosekunden wertest du nix aus... zumindest nicht über Assembler/C.. (is ja schließlich ein MICROprozessor.. und kein NANOprozessor ;-) ... so scherz bei seite... ich glaub an dem Konzept ist was net ganz richtig... erzeug im Controller einen Takt... z.b. über einen Timer.. und erzeuge eine ISR (interrupt service routine).. im 1 ms Takt. Wenn die Routine aufgerufen wird, wertest du beide Spuren A und B aus.. (über eine Look-Up-Table).. wie in der PDF die ich gepostet habe... Warum gehst du in eine Warteschleife, wenn eine Änderung erkannt wurde? Ahhh... meinst du etwa mit "Abtastung" die Controller-interne Flanken-erkennung? die einen Interrupt auslöst?? :-) dann reden wir hier aneinander vorbei! das sind 2 verschiedene Konzepte.. Abtastung arbeitet Takt-gesteuert ohne Flanken-Erkennung... hier werden nur Pegel ausgewertet! das andere Konzept.. ist Flankenerkennung (interrupt) und pegelauswertung! (dieses Verfahren ist UNGENAUER... und kann bei prellenden Encodern.. z.b. alten wie aus Computer-Mäusen ;-) zu unerwünscht vielen Interrupts.. Flanken führen.. die zu einer Fehl-Interpretation des SIgnals führen.. Für mich hört es sich so an als würdest du einfach die Spuren "pollen"... im Takt deines Controllers. Und wenn eine Flankenänderung erkannt wird wird ausgewertet... das klingt für mich nach einer selbstprogrammierten Flanken-Erkennung (Interrupt-mässig) das ist aber keine Abtastung... Abtastung heißt das Signal IMMER und IM GLEICHEN Takt zu analaysieren.. und abhängig davon wie die Pegel der spuren sind. Und diese Abtastungen auszuwerten... um zu codieren.. und dann per Look-Up-Table auszuwerten... Gruß seb
Ich taste im Takt des Mikrocontrollers ab. (ohne interrupt, ohne timer, kann das zu schnell sein?) wenn einer der beiden Spuren seinen Zusand (im gegensatz zum vorher gespeicherten Wert) ändert wird vor,bzw. zurückgezählt. momentan hab ich aber das Problem, dass die Spannung bei einem High nur ca. 1 Volt beträgt. war gesten noch nicht so. versuchma mal dieses Problem zu behebeh...
>Ich taste im Takt des Mikrocontrollers ab. (ohne interrupt, ohne timer, >kann das zu schnell sein?) Nicht zu schnell, aber zu ungenau... Hast du mal ein Oszi dran gehängt und geschaut wie lang die Pulse minimal sind? >momentan hab ich aber das Problem, dass die Spannung bei einem High nur >ca. 1 Volt beträgt. war gesten noch nicht so. Wie verbindet du die Spuren mit deinem Controller? Mein Tipp: Spur A --> Pull-Up (ca. 5 K gegen 5 V)... dann ein RC Glied... Widerstand ca. 10 K... Kondensator ca. 10 N... R*C--> 0.1 ms Zeitkonstante.. damit beugst du schon mal einem Prellen von 0.1 ms vor... wenn du dein Problem nicht über Timer-Interrupts und Abtastung lösten willst, dann dimensionier einfach deinen Tiefpaß richtig damit das Prellen deines Encoders ausgeglichen wird... ist zwar nicht schön. aber sollte fürs erste besser funktionieren.. Gruß
Ist über 10k auf +5V
1 | VCC |
2 | | |
3 | | |
4 | | |
5 | .-. |
6 | | | |
7 | | | |
8 | '-' |
9 | | |
10 | | |
11 | |---------- |
12 | | |
13 | | |
14 | \ o |
15 | \ |
16 | \. |
17 | o |
18 | | |
19 | |
20 | GND |
21 | (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de) |
dann auf µC wenn ich pegelproblem behoben hab, werd ich mal timer interrupts probieren. mfg J.K.
Wenn ich mit Multimeter mess, Schaltet 1 Spur zwischen 0,1 Ohm und Overflow (also >20MOhm) ...
hab zufällig noch ne 2. Maus herumliegen gehabt. mit dem neuen Drehimpulsgeber gehts wieder. auch die falsche Erkennung ist besser. Die Timerinterrupt-Variante werd ich mir aber auch noch ansehen. Danke Sebastian B. für deine Hilfe! @deinem Code: Danke, aber schreib ich mir lieber selber, lern ich vll was dabei ;-)
Mhm, sieht vernünftig aus... Warum ist dann aber der Pegel so niedrig.. bei offenem Encoder sollte ja VCC anliegen... wie gesagt Tiefpaß zur Glättung könnte auch nix schaden! Kannst ja R und C variieren... Hab dir gerade noch schnell ein Bild gemacht, wie das aussieht, wenn du "ganz schnell abtastest" (rote Striche).. aber dein Encoder prellt... also nicht sauber öffnet und schließt... daran kannst du ja die Problematik des "einfachen" Abtastens erkennen... Klar, seh ich auch so, dass man den code besser selbst schreibt! :-) Hab auch erst vor kurzem so richtig mit Hardware begonnen.. komme eher aus der Informatik... :-) deshalb kann ich dich gut verstehen. Das mit dem vorgänge Wert und dem aktuellen Wert machst du schon sehr richtig!! Aber ich würde dies noch nicht als festes Indiz für eine Auf/Abzählung nehmen... wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt wird... somit verkleinert sich auch die Wahrscheinlichkeit einer falsch-abtastung... Für was willst du den encoder eigentlich einsetzen? ODer ist das nur zum Testen? Könnte ich auch gut verstehen. Beste Grüße und noch viel Erfolg!
>wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte >Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt >wird... somit verkleinert sich auch die Wahrscheinlichkeit einer >falsch-abtastung... ok, werd ich machen bisweilen nur zum testen. vll bau ich mal einen "Kran", der sich durch ein Modell steuern lässt. der Drehimpulsgeber kommt ins Modell um die Drehung um die eingene Achse zu detektieren, am Kran kommt dann zb ein Schrittmotor, der die Drehung ausführt. mfg J.K
wollte grad anfangen zu programmieren da ist mir aufgefallen: >wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte >Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt >wird... somit verkleinert sich auch die Wahrscheinlichkeit einer >falsch-abtastung... mir ist der Vorteil schon klar, aber wird aber die Auflösung halbiert?! die 4 Graycode zustände wiederholen sich mit 2 Rasterpunken. Naja, wird auf einen Kompromiss hinauslaufen müssen 1. sicherer oder 2. höhere Auflösung mfg J.K
Soweit ich weiß braucht man beim Abtastprinzip (Standard Dannegger Code) überhaupt keine Entprellung vorsehen, da der Gray-Code in diesem Sinne Prellsicher ist. Nachdem der Encoder sich also in den nächsten Raster fertiggeprellt hat, stimmt der Wert wieder.
Hi >wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte >Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt Ich denke, er meinte: '4 gleiche Codes'. MfG Spess
Simon K. wrote: >Soweit ich weiß braucht man beim Abtastprinzip (Standard Dannegger Code) >überhaupt keine Entprellung vorsehen, da der Gray-Code in diesem Sinne >Prellsicher ist. Nachdem der Encoder sich also in den nächsten Raster >fertiggeprellt hat, stimmt der Wert wieder. Hallo, das stimmt, der Gray-Code den die Spuren erzeugen und die Auswertung schützen vor Falsch-Erkennung. Jetzt kommt aber ein kleines "aber": Der Encoder prellt ja trotzdem ein wenig.. Ich bin jetzt auch kein Profi auf diesem Gebiet, wenn man aber jetzt noch einen kleinen Tiefpaß nach den Signalen reinsetzt, dann wird ja das Prellen schon mal verringert, falls man wirklich mal ungünstigerweise in so einen "Prell-Zeitpunkt" reintasten sollte... Ist nicht zwingend erfoderlich, da ja die Code-Auswertung, diese Fehler erkennen kann. @spess53: >>wenn du den GrayCode benutzt... dann sage ich z.b. müssen 4 korrekte >>Codes aufeinander folgen damit ein vollständiger Dreh-Puls erkannt >Ich denke, er meinte: '4 gleiche Codes'. Ich versuche meine Abtastfrequenz so zuwählen, dass ich (mindestens) 4 mal in einen Dreh-Impuls hineintasten kann. Wenn man sich einen Puls auf 2 Spuren (A und B) mal aufzeichnet, wenn sie 90 GRad zu einander Phasen versetzt sind und dann im gleichen Abstand vertikale (Abtast)-Striche einzeichnet, dann kann man an den Strichen Kombinationen ablesen... Z.b. Spur A: 0 Spur B: 1... --> Nun kommt der Trick bei der Auswertung diese Zustandspaare z.B. 0;1 werden umcodiert. Für jedes mögliche Paar wird ein Zustand definiert... So ergeben sich logischerweise 4 mögliche Zustände. Diese 4 möglichen Zustände varrieren in ihrer Reihenfolge ob man nach Links oder Rechts dreht. Die Auswertung erfolgt nun folgendermaßen: Aus altem Zustands-Code und neuem Zustands-Code lässt sich nun ein "Indikator" für die Drehrichtung erkennen... (siehe dazu Look-Up-Table aus der PDF aus meinem Posting...) aus dieser Look-Up-Table lässt sich nun dieser Indikator ablesen. Anhand eines korrekten Zustands-Übergangs, wie ich es jetzt mal nenne, lässt sich aber noch nicht vorhersagen ob es sich um einen korrekten Links oder Rechts-Puls handelt. Es müssen also 4 korrekte INDIKATOREN erkannt werden bis ein PULS erkannt wird. Das hängt zum einen mit der Abtastgenauigkeit und der Code-Folge zusammen. @J.K >mir ist der Vorteil schon klar, aber wird aber die Auflösung halbiert?! >die 4 Graycode zustände wiederholen sich mit 2 Rasterpunken. >Naja, wird auf einen Kompromiss hinauslaufen müssen >1. sicherer oder >2. höhere Auflösung Die Gray-Code Zustände wiederholen sich bei JEDEM Rasterpunkt. Durch die Abtastung mit 4-fach höherer Abtastfrequenz als maximale Puls-Frequenz ist die Genauigkeit verVIERfacht. Es ist sicherer und genauer.
@ Sebastian B. (Firma cD) (mircobolle) >Jetzt kommt aber ein kleines "aber": Der Encoder prellt ja trotzdem ein >wenig.. Erfinde das Rad nicht neu und eckig. Du hast ja deine Informationen schon hier aus dem Wiki. Dann liess sie noch mal und denk drüber nach, anstatt wilde Theorien aufzustelln. a) Die im Wiki gezeigten Routinen werden durch prellende Encoder KEIN BISSCHEN aus dem Tritt gebracht. PUNKT! >Ich versuche meine Abtastfrequenz so zuwählen, dass ich (mindestens) 4 >mal in einen Dreh-Impuls hineintasten kann. b) Es muss pro CODEWECHSEL mindestens eine Abtastung erfolgen, mehr schaden nicht. PUNKT. >Wenn man sich einen Puls auf 2 Spuren (A und B) mal aufzeichnet, wenn >sie 90 GRad zu einander Phasen versetzt sind und dann im gleichen Dumm nur, dass gerade billige Encoder alles andere als 90 Grad Phasenversatz haben. Da gabs schon welche mit 30 Grad und weniger!. >--> Nun kommt der Trick bei der Auswertung diese Zustandspaare z.B. 0;1 >werden umcodiert. Für jedes mögliche Paar wird ein Zustand definiert... >So ergeben sich logischerweise 4 mögliche Zustände. Vollkommen unötig, von Peters Ultrakompaktroutine mal abgesehen. >Es müssen also 4 korrekte INDIKATOREN erkannt werden bis ein PULS Was soll ein INDIKATOR sein? >erkannt wird. Das hängt zum einen mit der Abtastgenauigkeit und der >Code-Folge zusammen. ???? MFG Falk
Ich bin gerne für Kritik offen. Aber das was jetzt hier passiert finde ich nicht mehr i.O. Ich dachte ich könnte mit ein paar Informationen helfen. Ich hatte Auszüge aus meiner Master-Thesis und meine Routine veröffentlicht. Ich sehe nun keine Berechtigung warum "Falk Brunner" mich hier im Forum auseinander zunehmen versucht. Falls ich mich umständlich ausgedrückt haben sollte war das sicher unglücklich und auch, wenn manche Informationen sogar falsch gewesen sein sollten. Ich habe es so wieder gegeben wie ich es verstanden habe, wie ich es mit einem Oszilloskop verifiziert habe und ich wie es implementiert und getestet habe. Die Routine funktioniert sehr gut - ich habe keinen Grund mich jetzt dafür zu verstecken. Es waren Beispiels die ich gebracht habe - falls man sie nicht verstehen konnte dann ist das sicherlich unglücklich. Es ist eine Sache Informationen zu veröffentlichen (wie es hier Wiki geschieht). Diese Informationen müssen dann nur noch auf eine konkrete Problemstellung angewandt werden. Es ist egal um wie groß der Phasenversatz ist. Hauptsache es entsteht eine Code-Folge. Mir war es nicht klar, dass ich das Rad nochmal eckig nach erfinde. Was gelinde gesagt eine grobe Unverschämtheit ist - so eine Aussage. Hast du mein Posting überhaupt gelesen oder bist du nur auf ein paar Schlagwörter angesprungen und dachtest du müsstest deinen Senf dazu abgeben. Ich habe jetzt nicht verifiziert wie ein Encoder sich verhält wenn er prellt. Was ich jedoch weiß: Die Code-Folge schützt vor Abtastfehlern die durch Prellen entstehen (PUNKT) Die Code-Folge schützt in geringem Masse vor Aliasing-Fehlern die durch Unterabtastung entstehen (PUNKT) Wenn ein Encoder prellt und in so einen Fehlerfall hineingetastet wird schützt die Code-Folge vor Falscherkennung (PUNKT) Wenn nun aber ein Tiefpaß davor sein sollte, der die Flankensteilheit etwas abflacht und schnelle Pegel-Wechsel durch Prellen verursacht unterdrückt... ist das sicher kein Fehler. Ich habe nichts neu erfunden.
Sebastian B. wrote: > Die Code-Folge schützt vor Abtastfehlern die durch Prellen entstehen > (PUNKT) > Die Code-Folge schützt in geringem Masse vor Aliasing-Fehlern die durch > Unterabtastung entstehen (PUNKT) > > Wenn ein Encoder prellt und in so einen Fehlerfall hineingetastet wird > schützt die Code-Folge vor Falscherkennung (PUNKT) > ... > Wenn nun aber ein Tiefpaß davor sein sollte, der die Flankensteilheit > etwas abflacht und schnelle Pegel-Wechsel durch Prellen verursacht > unterdrückt... ist das sicher kein Fehler. Das gibt für mich überhaupt keinen Sinn, du sagst doch quasi geradezu dass der Tiefpass Unsinn ist. Dass er nicht Schaden kann, ist uns allen klar. Es geht darum diesen wegzulassen, was definitiv in Ordnung ist.
Ganz einfach: Lass ihn weg. (Wenn deine Routine dann aber weniger oft den Fehler-Fall erkannt und somit jeder Raster-Punkt auch immer als Puls erkannt werden kann is das sicher auch net so schlecht) Was soll das ganze eigentlich? In meinem Fall ist das nur ein Drehknopf. Ich steuere damit ein rotierendes Display-Menü. Stelle Werte ein. Es funktioniert! Denkt mal ein bisschen mehr Ingenieurs-mäßiger. Das Ding soll möglichst gut funktionieren. That's it.
Sebastian B. wrote: > Mehr Infos siehe Dateianhang... > > das ist ne ganz gute Erklärung zu dem ganzen Thema! Entschuldigung, das finde sogar ich ein wenig halbgar. "Die Auswertung der Drehgeber Signalspuren erfolgt nicht über Flankenerkennung und Pegelauswertung von B, da dies einige Nachteile mit sich bringt:" "Die Auflösung wird auf ein Viertel reduziert, weil nur jede steigende Flanke von A ausgewertet wird." Zusammenhang? Und wenn man beide Flanken auswerten würde hätte man die halbe Auflösung? Plausibilität? "Pendelt der Encoder zwischen zwei Codes, bei denen A seinen Pegel wechselt, kommt es zu (sehr) vielen Interrupts, die den MikroController vollkommen auslasten können." Was hat das Auswerten der Flanken im Allgemeinen mit Interrupts im Speziellen zu tun? Wenn man dafür sorgt, dass das Signal nicht prellt und man bei zyklischer Abtastung von A eine Zustands-Änderung erkennt, funktioniert eine Betrachtung von B zum Zeitpunkt der Zustands-Änderung von A sehr wohl ganz hervorragend und zuverlässig. Wenn man den nackten Drehimpulsgeber mit Pullup-Widerständen benutzt ist das sicherlich nicht ein Weg der leicht sauber ans Ziel führt.
@ Sebastian B. (Firma cD) (mircobolle) >Ich bin gerne für Kritik offen. Wirklich? >Ich sehe nun keine Berechtigung warum "Falk Brunner" mich hier im Forum >auseinander zunehmen versucht. Mach ich nicht. >Ich habe es so wieder gegeben wie ich es verstanden habe, wie ich es mit >einem Oszilloskop verifiziert habe und ich wie es implementiert und >getestet habe. Sicher, was aber nicht heisst, dass es richtig ist, wie du selber geschrieben hast. >Die Routine funktioniert sehr gut - ich habe keinen Grund mich jetzt >dafür zu verstecken. Nöö, aber man kann sie kritisieren. >Es ist eine Sache Informationen zu veröffentlichen (wie es hier Wiki >geschieht). Diese Informationen müssen dann nur noch auf eine konkrete >Problemstellung angewandt werden. Diese Formulierung "nur noch" würde ich sparsamer einsetzen. Den gerade bei diesem "nur noch" hapert es oft in der Praxis. >Es ist egal um wie groß der Phasenversatz ist. Hauptsache es entsteht >eine Code-Folge. Ein Irrtum. Stell dir vor, dein Encoder macht 20 Codes/U und dreht mit max. 10 U/s. Macht 200 Codes/s mit 5ms Codedauer, WENN die beiden Spuren A und B exakt 90Grad Phasenversatz haben. Eine Abtastung mit etwas über 200 Hz ist dan ausreichend. ABER Wenn der Phasenversatz auf grund schlechter Qualität, Produktionsfehler etc. nur 45 Grad beträgt, dann verschluckt eine Abtastung mit knapp über 200 Hz Schritte. Das ist aber allgemein so und NICHT auf deinen Code beschränkt. >Mir war es nicht klar, dass ich das Rad nochmal eckig nach erfinde. Was >gelinde gesagt eine grobe Unverschämtheit ist - so eine Aussage. Soviel zu deiner Kritikfähigkeit. >Hast du mein Posting überhaupt gelesen Durchaus. >Ich habe jetzt nicht verifiziert wie ein Encoder sich verhält wenn er >prellt. Aha, plötzlich backen wir doch kleine Brötchen. > Was ich jedoch weiß: >Die Code-Folge schützt vor Abtastfehlern die durch Prellen entstehen >(PUNKT) >Die Code-Folge schützt in geringem Masse vor Aliasing-Fehlern die durch >Unterabtastung entstehen (PUNKT) >Wenn ein Encoder prellt und in so einen Fehlerfall hineingetastet wird >schützt die Code-Folge vor Falscherkennung (PUNKT) Du macht verdammt viele Punkte mit deinen jungen Jahren. Ich sehe ja ein dass deine Masterthesis im Moment der Mittelpunkt deines Lebens ist und du sie für das Wichtigste in der Welt hältst. Aber andere Leute vieleicht nicht. Und erst recht nicht, wenn du dich bockig hinstellst, dich Kritik verweigerst und dann noch Unsinn erzählst. >Die Code-Folge schützt in geringem Masse vor Aliasing-Fehlern die durch >Unterabtastung entstehen (PUNKT) Ist schlicht falsch, weil das Abtasttheorem hier gar keine sinnvolle Anwendung erfährt. Wir tasten asynchron ein Digitalsignal ab, kein (bandbegrenztes) Analogsignal. Und der Graycode schützt KEIN bisschen vor Unterabtastungsfehlern. >Wenn nun aber ein Tiefpaß davor sein sollte, der die Flankensteilheit >etwas abflacht und schnelle Pegel-Wechsel durch Prellen verursacht >unterdrückt... ist das sicher kein Fehler. Hat keiner behauptet. >Ich habe nichts neu erfunden. Aber du schreibst gern alles nochmal ab, was schon mehrfach in Links (besser) dargestellt wurde. ;-) MFG Falk P.S. Zur Kritkfähigkeit gehört auch, nicht immer gleich alles persönlich zu nehmen und den Kopf zu verlieren.
@ Sebastian B. (Firma cD) (mircobolle) >Was soll das ganze eigentlich? >In meinem Fall ist das nur ein Drehknopf. >Ich steuere damit ein rotierendes Display-Menü. Stelle Werte ein. >Es funktioniert! Ach plötzlich? Und wozu der Ganze Aufriss dann? >Denkt mal ein bisschen mehr Ingenieurs-mäßiger. Das tun die meisten hier mehr, als du dir vorstellen kannst. Nun dass "ingenieurmässig denken" != "Hobbybastlerdenken" ist, ala "Bei mir läuft der UART auch mit RC-Oszillator stabil." ;-) MFg Falk
Hallo Falk, ok, jetzt habe ich meinen Zustand etwas "stabilisiert" ;-) Aber ist verständlich, dass vielleicht etwas empfindlich auf Kritik gegen meine Master-Thesis verstehe (die gerade schreibe...). Aber sei es drum ihr habt sicher mehr Erfahrung und das akzeptiere ich. Schließlich will ich ja dazu lernen. Vor einem halben Jahr hatte ich nicht mal ne Ahnung davon was ein Encoder ist. (ich studiere Informationstechnik..) Von wegen Abtasttheorem: Mit Aliasing habe ich gemeint, dass bei schnellen Pegel-Wechseln (schnellem Drehen) und bei zu geringer Abtastfrequenz ein Aliasing Effekt entsteht... Wenn mein Signal mit 100 Hz seine Pegel wechselt und ich beispielsweise mit 50 Hz abtaste will ja wohl keiner bestreiten, dass das nicht funktioniert. >Aber du schreibst gern alles nochmal ab, was schon mehrfach in Links >(besser) dargestellt wurde. ;-) Hast du die Look-Up-Tabele Darstellung aus meiner PDF gesehen ? Ich finde diese Darstellung ist mir ganz gut gelungen.. ;-) Scherz bei Seite... ok, das nächste mal stell ich nur noch einen Link zu einem Wiki Artikel rein und erspar mir den Zirkus Prost Mahlzeit
@ Sebastian B. (Firma cD) (mircobolle) >Von wegen Abtasttheorem: >Mit Aliasing habe ich gemeint, dass bei schnellen Pegel-Wechseln >(schnellem Drehen) und bei zu geringer Abtastfrequenz ein Aliasing >Effekt entsteht... Weisst du überhaupt, was der Aliasing-Effekt WIRKLCIH ist? Wenn ich einen 1 KHz Sinus mit 10 kHz abtaste, werde ich in den digitalen Daten den auch ganz gut wiedererkennen. Wenn ich mit 2 kHz abtaste, ist das THEORETISCH noch machbar, PRAKTISCH aber zu langsam, wenn ich z.B. immer die Nulldurchgänge erwische. Taste ich mit 800 Hz ab, sehe ich in den digitalen Daten plötzlich einen Sinus von 2*800Hz-1kHz = 600 Hz. Und wenn ich nicht anderweitig weiss, dass es aber 1 kHz sein muss, kann ich mich sehr schön verarschen lassen. ;-) Kann man sehr einfach mit einen Digitaloszilloskop zeigen. Sinus einspeisen und Zeitauflösung MASSIV runterdrehen. Man sieht wieder einen Sinus mit vollkommen falscher Frequenz. Ein Analogoszi würde richig einen breiten Strich zeigen. >Wenn mein Signal mit 100 Hz seine Pegel wechselt und ich beispielsweise >mit 50 Hz abtaste will ja wohl keiner bestreiten, dass das nicht >funktioniert. Hat keiner bestritten, ist aber wie gesagt nicht wirklich Aliasing. >Aber du schreibst gern alles nochmal ab, was schon mehrfach in Links >(besser) dargestellt wurde. ;-) >Scherz bei Seite... ok, das nächste mal stell ich nur noch einen Link zu >einem Wiki Artikel rein und erspar mir den Zirkus Wenn du viel Energie hast, kannst du auch einen Wikiartikel schreiben oder erweitern. Das bringt allen mehr, vor allem weil dann die Informationen GEBÜNDELT und SCHELL aufindbar vorliegen, nicht verstreut in 1001 Thread. MFG Falk
Rudolph R. wrote: > ... Was ist an den Aussagen jetzt halbgar? > Was hat das Auswerten der Flanken im Allgemeinen mit Interrupts im > Speziellen zu tun? Sorry, aber diese Frage verstehe ich nicht. "im Allgemeinen" und "im Speziellen" widerspricht sich. > Wenn man dafür sorgt, dass das Signal nicht prellt und man bei > zyklischer Abtastung von A eine Zustands-Änderung erkennt, funktioniert > eine Betrachtung von B zum Zeitpunkt der Zustands-Änderung von A sehr > wohl ganz hervorragend und zuverlässig. Ja, es ist ja auch eine mögliche Methode das so zu machen. > Wenn man den nackten Drehimpulsgeber mit Pullup-Widerständen benutzt ist > das sicherlich nicht ein Weg der leicht sauber ans Ziel führt. Da hat du es, und deswegen benutzt man lieber einen anderen Weg (zum Beispiel die Abtastung). Da brauchts dann auch keine Entprellung mehr und das ist ein eindeutiger Vorteil. Falk: Du bist heute aber auch wieder ziemlich grob zu den Leuten ;)
@ Simon K. (simon) Benutzerseite
>Falk: Du bist heute aber auch wieder ziemlich grob zu den Leuten ;)
Es ist Sonntag, und mein Kreidevorrat ist erschöpft . . . ;-)
MFG
Fa - der böse Wolf - lk
Simon K. wrote: > Rudolph R. wrote: >> ... > Was ist an den Aussagen jetzt halbgar? Was ich meine habe ich schon geschrieben. >> Was hat das Auswerten der Flanken im Allgemeinen mit Interrupts im >> Speziellen zu tun? > Sorry, aber diese Frage verstehe ich nicht. "im Allgemeinen" und "im > Speziellen" widerspricht sich. Die Ansage im verlinkten Dokument ist erstmal ganz allgemein, dass auf eine Flanken-Auswertung verzichtet wurde, da das Nachteile hat. Und unter der Auflistung der Nachteile tauchen plötzlich Interrupts auf, was wiederrum eine spezielle Methode der Flanken-Auswertung darstellt. >> Wenn man dafür sorgt, dass das Signal nicht prellt und man bei >> zyklischer Abtastung von A eine Zustands-Änderung erkennt, funktioniert >> eine Betrachtung von B zum Zeitpunkt der Zustands-Änderung von A sehr >> wohl ganz hervorragend und zuverlässig. > Ja, es ist ja auch eine mögliche Methode das so zu machen. > >> Wenn man den nackten Drehimpulsgeber mit Pullup-Widerständen benutzt ist >> das sicherlich nicht ein Weg der leicht sauber ans Ziel führt. > > Da hat du es, und deswegen benutzt man lieber einen anderen Weg (zum > Beispiel die Abtastung). Nochmal lesen, Abtastung führe ich auch auf, die Auswertung ist anders. > Da brauchts dann auch keine Entprellung mehr > und das ist ein eindeutiger Vorteil. Keine Frage.
Leute seid nett zueinander! Ich finde nicht dass jemand runtergemacht werden sollte, nur weil er nicht den Wissensstand wie man selbst hat! @topic >Die Gray-Code Zustände wiederholen sich bei JEDEM Rasterpunkt. >Durch die Abtastung mit 4-fach höherer Abtastfrequenz als maximale >Puls-Frequenz ist die Genauigkeit verVIERfacht. >Es ist sicherer und genauer. ah, da liegt der Hund begraben! bei meinem Drehgeber widerholen sich die 4 Zustände nur alle 2 Rasterpunkte. (wie im Wikiartikel)
OK, die Abtastlösung funktioniert um einiges besser! Hab zuerst mit 1kHz abgetastet. Da hatte ich aber das Problem, dass oft die Phasenverschiebung nicht erkannt wurde. Die Spuren sind von 00 auf 11 (Rasterpunkte) gesprungen. Eine Drehung wurde nur erkannt, wenn sehr langsam gedreht wurde. hab jetzt auf 5 kHz erhöht, ist aber nicht viel besser geworden. in anderen Beiträgen (Beitrag "Drehimpulsgeber mit Rasterstellung bei 00/11 auswerten") ist von 500Hz die Rede. soll ich einfach weitererhöhen? Welche Abtastrate ist in diesem Fall ist "normal"? Kann man da eine Aussage machen?
also ich taste mit 1 kHz - jede 1 ms - die Spuren A und B ab. So, dass ich alle 4 Zustandsänderungen pro Rasterung mitbekomme. Ich habe mir ausgerechnet, dass ich mit einer Abtastfrequenz von 1 kHz und 15 Rasterpunkten (alle 15 Grad) somit mit einer maximalen Drehzahl von etwa 3750 Grad Sek - also etwa 10 Umdrehungen Sekunde meinen Drehgeber drehen kann und die Drehrichtung noch korrekt erkannt werden kann.
>ah, da liegt der Hund begraben! bei meinem Drehgeber widerholen sich die >4 Zustände nur alle 2 Rasterpunkte. (wie im Wikiartikel) Anhand deiner Aussage würde ich sagen du brauchst, nicht wie ich 4 Zustandswechsel, sondern nur 2. Damit würde sogar eine niedrige Abtastfrequenz ausreichen.. Aber mit 1 kHz und normaler Drehgeschwindigkeit sollte es auf jeden Fall gehen. Andere Frage: - Was für einen Controller verwendest du? - Assembler oder C ?
hello, I think I have alomst the same problem like J.K. Sorry, my german is not really good. I'm from norway but I stay here in germany for my semester abroad. I'm interessted in microcontroller programming. So what I did unterstand is that the econding of the rotary encoder didn't worked correct... so he had to changed his programming concept. Could somebody describe me how the encoding works best? I saw this PDF Document above my post... I liked the pictures, which helped me a lot to get how the ecnoder works... espacially the signal waveform of the encoder. Thanks a lot! Yngvar
@Yngvar (Gast) >Could somebody describe me how the encoding works best? Look here, but german only. Sorry. Drehgeber Regards Falk
Hello Falk, thank you for your fast response! So I will look at your linked document, so I can improve my german-reading skills, too. I have another question, but with the same background. Does encoder exists, that have more then the normal 'left / right' direction? Does encoder exists, which are able to be controlled by different movements additional to the 'left/rigt' direction... like a joy-stick, that can be moved in 4 directions and could be pushed too. all this controls in one device would be fantastic... so I think Thanks a lot! Yngvar
@Yngvar (Gast) >Does encoder exists, that have more then the normal 'left / right' >direction? Some have a zero indicator signal, so you can reset your counter and have a absolut position. > Does encoder exists, which are able to be controlled by >different movements additional to the 'left/rigt' direction... like a >joy-stick, that can be moved in 4 directions and could be pushed too. Push buttons are quiet common, more than one axis AFAIK not. >all this controls in one device would be fantastic... so I think Such things are usually doe using a analoge joystick, controlled by two potentiometers. The only two axis device I know is the classic mechanical mouse. Regards Falk
>Andere Frage: >- Was für einen Controller verwendest du? >- Assembler oder C ? >-MEGA16 >-C Die eine Richtung funktioniert auch sehr gut, die andere weniger. Mir scheint, dass in die eine Richtung ein gößerer Abstand ist als in die andere. (Habe mir die Portzusände über die RS232 ausgebenlassen) >The only two axis device I know is the classic mechanical mouse. My mechanical mouse works with 2 light barriers. There are two axis. On the ends are plates with gaps, which interrupt the beam.
>Habe mir die Portzusände über die RS232 ausgeben lassen
das war der Fehler!!!
Die Übermittlung des der Werte (mit kleiner Beschreibung dauerte zulang)
9600 Baud
//printf("\rZahl:%3i Spur A B %i %i Zustand: %i",z,PIND.6,PIND.7,zust);
ca 35 zeichen
bei 9600 zeichen pro sekunde
sind das 3,64 ms !
mfg
J.K
Yngvar wrote: regarding the rotary encoders: on page 7 this pdf elaborates pretty much both rotation recognition methods: http://www.altron.de/_pdf/ddm/427z1.pdf even in english, though ^^ > I have another question, but with the same background. > > Does encoder exists, that have more then the normal 'left / right' > direction? Does encoder exists, which are able to be controlled by > different movements additional to the 'left/rigt' direction... like a > joy-stick, that can be moved in 4 directions and could be pushed too. alps does produce such devices, listed under joysticks. couldn't find em right now, but they exist ^^
I think you mean something like this: http://www.reichelt.de/?;ACTION=3;LA=4;GROUP=B254;GROUPID=3136;ARTICLE=73910;START=0;SORT=order_col_artnr_besch;OFFSET=1000;SID=27IccPeqwQARsAAF1rEUka2f8977631b435d9df618a4597ddbe88 The order number is RKJXP122002
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.