Servus :-) Hat jemand eine Idee, wie man einen Drehimpulsgeber entprellet? Ich hab hier so ein Sch...ßteil, welches derart prellt, dass sich garnichts damit anfangen lässt. Springt pro Impuls germ mal 1-8 Schritte vor oder auch zurück, egal welche Richtung man dreht. Nur wenn man gaaaaaanz langsam dreht, dann läuft er in die Richtung, wo er soll. Aber immer noch mit teilweise gewaltigen Schritten. Hier ist der Link zum Hersteller, der noch nichtmal n vernünftiges Datenblatt hat: http://www.tokyoden.com/product/html/encoder/EC11-e.htm Ich empfehle jedem, das Ding NICHT zu kaufen. Leider hatten Sie im Bastlerladen nix anderes, sonst hätt ich nen optischen Geber gekauft. Mein Testprogramm dazu, vielleicht hat ja jemand ne Idee, wie man das anders lüsen kann: $regfile = "m32def.dat" $crystal = 16000000 $swstack = 50 $hwstack = 50 $framesize = 50 Config Lcdpin = Pin , Db4 = Portc.4 , Db5 = Portc.5 , Db6 = Portc.6 , _ Db7 = Portc.7 , E = Portc.3 , Rs = Portc.2 Config Lcd = 16 * 4 Cls Cursor Off Config Pinb.2 = Input Portb.2 = 1 Config Pinb.4 = Input Portb.4 = 1 Config Pinb.5 = Input Portb.5 = 1 Dim Zustand As Byte Dim Flag As Bit Dim Wert As Byte Flag = 0 Do Zustand = Encoder(pinb.4 , Pinb.5 , Linksroutine , Rechtsroutine , 1) Cls Locate 1 , 1 Lcd Zustand Locate 2 , 1 Lcd Wert Locate 3 , 1 Lcd Flag Loop End Rechtsroutine: Incr Wert Return Linksroutine: Decr Wert Return
Ein Encoder liefert Gray-Code, der ist quasi selbst entprellend, da sich immer nur ein Signal zur Zeit ändert. Der Trick ist, daß man alle 4 Phasen auswerten muß, auch wenn nur alle 2 oder 4 Phasenwechsel eine Rastung erfolgt. Für manuelle Encoder ist ein Timerinterrupt oder ein Pin-Change-Interrupt auf beide Signale dazu optimal. Peter
>Für manuelle Encoder ist ein Timerinterrupt oder ein >Pin-Change-Interrupt auf beide Signale dazu optimal. optimal ja - aber es würde sogar ausreichen, wenn man das per Polling abfägt. Man muss lediglich sicherstellen, dass man pro 90° mindestens ein mal die Auswertung durchführt.
Jack Ganssle hat zu dem Thema eine ganz andere Meinung: Prellende Signale sollte man NIEMALS auf Interrupt-Eingänge geben: http://www.ganssle.com/debouncing.htm (falls Englisch kein Hindernis ist)
Uwe Heydemann schrieb: > Ich empfehle jedem, das Ding NICHT zu kaufen. Nur weil du den Gray-Code nicht ausgewertet kriegst?
Bastler schrieb: > Uwe Heydemann schrieb: >> Ich empfehle jedem, das Ding NICHT zu kaufen. > > Nur weil du den Gray-Code nicht ausgewertet kriegst? Nee, weil das Ding auch qualitativ Müll ist. Dann erklär mir doch bitte mal jemand, wie man den Gray-Code mit Bascom auswertet. Ich dachte eigentlich, dass das mit der ENCODER-Routine bei Bascom entfällt...
@ Uwe Heydemann (uwe1981) >auswertet. Ich dachte eigentlich, dass das mit der ENCODER-Routine bei >Bascom entfällt... Eigentlich schon, manchmal nicht. Als erste Aktion könnte man A und B vertauschen, klingt unsinnig, ist es aber bisweilen nicht. Siehe Artikel. Wenn das nicht hilft, muss man weiter sehen. MFG Falk
Ich weiß nicht, wie die Encoder-Funktion in Bascom definiert ist > Encoder(pinb.4 , Pinb.5 , Linksroutine , Rechtsroutine , 1) aber ich weiß, wie man es richtig macht, so daß Encoderprellen keinerlei Rolle spielt: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
MaWin schrieb: > http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 Dort ist in der Tabelle von Michael Biere die Reihenfolge der Zustände allerdings etwas gewürfelt. So stellt das keine Gray-Code dar. ;-)
So wie ich das sehe soll das auch keine Tabelle der im Laufe einer Umdrehung nacheinander auftretenden Zustände sein, sondern einfach eine Auflistung der 4 möglichen Zustände, also Binärzahl sortiert. Aber dein Vorschlag, das anders anzuordnen, ist angenommen.
MaWin schrieb: > So wie ich das sehe soll das auch keine Tabelle der im Laufe > einer Umdrehung nacheinander auftretenden Zustände sein, Stimmt. Die richtige Reihenfolge würde auch besser zum nachfolgenden Beispiel passen. Und wenn du schon am Ändern bist: Das Stichwort "Gray-Code" würde da auch irgendwie hingehören.
Utah schrieb: > Mit 100nf gegen Masse entprellen wirkt Wunder ! Löst das Problem aber nicht, sondern begrenzt nur unnötig die Schrittfrequenz. Spätestens bei einer Maschinensteuerung geht man damit fürchterlich baden.
Die Kondensatoren natürlich zusätzlich zur Softwareentprellung! Das funktioniert bei Handbetrieb nachensicher und verlangsamt nichts .
Utah schrieb: > Die Kondensatoren natürlich zusätzlich zur Softwareentprellung! 1. Wenn die Softwareentprellung funktioniert, ist ein Kondensator einfach überflüssig. 2. Jeder Schaltvorgang auf "0" stellt einen Kurzschluß des zum Ausgang parallel geschalteten Kondensators dar, d.h. es fließen hohe Spitzenströme, die zu Kontaktabbrand führen und die Kontaktlebensdauer verringern.
Hi Uwe, such dir doch eine von den vieren hier aus: http://www.rn-wissen.de/index.php/Drehencoder Ich persönlich bevorzuge die vierte. Gruß KH
Es gibt einen einfachen Test, ob der Algorithmus was taugt: Eine Leitung A oder B abziehen. Wenn beim Drehen der Zähler weiter hoch zählt, ist es ein "Sparalgorithmus", der immer noch viel zu oft verwendet wird.
Klaus Heissler schrieb: > Ich persönlich bevorzuge die vierte. ich würde vor Eingang in die Sprungtabelle nicht die Pin-Werte direkt verwenden sondern den Entprellten Status der Pins. z.B. mit entprellter Zustand = nur setzen falls letzter Pinzustand und aktueller Zustand gleich sind. Gruß Anja
Danke für die Tipps, ich hab mir von der Seite RN-Wissen einen Code gezogen, der funktioniert. Das Ganze hat nur einen Nachteil: Der Timer0 ist nun besetzt. Ich bräuchte eigentlich für mein Projekt die drei Timer für andere Aufgaben. Kann man eigentlich einen Timer für mehrere Aufgaben nebeneinander nutzen? Ich wollte den Timer0 eigentlich zum Wecken des Prozessors aus dem Powerdown-Modus verwenden. Timer1 ist für PWM reserviert und Timer2 für Drehzahlmessung. Nun ist Timer0 mit dem Encoder belegt und ich rätsel nun, wie ich den Prozessor wecke... Hat da jemand ne Idee?
Uwe Heydemann schrieb: > Kann man eigentlich einen Timer für mehrere Aufgaben nebeneinander > nutzen? Windows kann das. Es ist also nur eine Frage der Programmierung. > Nun ist Timer0 mit dem > Encoder belegt und ich rätsel nun, wie ich den Prozessor wecke... Solang der uC schläft, kannst du sowieso keinen Geber einlesen. Und wenn der Controller läuft, brauchst du den Timer nicht zum Aufwecken.
Zweite Frage: Wird eigentlich jeder Drehencoder mit dem gleichen Code entprellt oder muss man für verschiedene Encoder den Quellcode modifizieren?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.