Encoder lesen, Problem mit Code

Was genau ist das für ein Encoder? Hast Du die Impulse mal gemessen oder 
analysiert?

Ja ich habe kurz mit dem Ohmmeter nachgemessen und festgestellt, dass 
tatsächlich immer A und B entweder hoch oder tief sind. Eigentlich bin 
ich davon ausgegangen, dass es sich um einen "normalen" Encoder handelt, 
der in allen 4 Zuständen rastet, erst anhand des Datenblatts (beiliegend 
ein Ausschnitt) bin ich stutzig geworden. Diese Art von Encoder wird 
"incremental" genannt. Bei meiner Suche wurde ich dann im oben erwähnten 
Thread fündig.

Das gesamte Datenblatt kann hier

http://docs-europe.electrocomponents.com/webdocs/07a2/0900766b807a2223.pdf

heruntergeladen werden.

Gruss
Martin

Das Ohmmeter sagt ja nichts darüber aus, was beim Drehen passiert. Hier 
werden nämlich zeitlich aufeinanderfolgende Flanken ezeugt. Dies muß der 
Code natürlich auch richtig interpretieren. Andere Encoder arbeiten nach 
einem anderen Prinzip (Gray-Code), wo bei jeder Rastung erst ein, dann 
der andere Ausgang seinen Pegel wechselt.

Ich habe mir das jetzt nochmal in Ruhe überlegt, und bin zum Schluss 
gekommen, dass mein Problem wohl mit ungenügender Entprellung des 
Encoders zusammenhängt. Weil wenn ich gaaaaanz langsam drehe geht es 
auch abwärts korrekt.

Kann mir jemand auf die Sprünge helfen mit dem Entprellen? Kann ich den 
oben geposteten Code softwaremässig entprellen, wenn ja wie?

Gruss
Martin

Laut Datenblatt einfach Kondensatoren von den A/B-Pins jeweils nach 
Masse, so 100nF Keramik. Dann ist´s mit dem Prellen vorbei. Die PullUps 
im Controller machen den Rest.

Das scheint nicht zu reichen, ich hatte auch schon vom Entprellen mit 
Kondensator gelesen und hatte gerade 100n Keramik da. Ich hätte eher 
grössere genommen aber nahm das was ich hatte. Soll ich mit grösseren 
Kondensatoren versuchen?

Falls wer noch eine Idee für Softwareentprellung hat wär das trotzdem 
noch einen Versuch wert.

Gruss
Martin

Hier ist ne Lösung:

Beitrag "Re: Drehgeber auslesen"

bezogen auf die darüber liegenden Files von Simon.


Mein Code (2.Posting) behandelt ja alle 4 Phasen.


Peter

Ein Versuch mit 10µF Elkos brachte auch keinen weiteren Erfolg, das 
sollte ja weitaus genügen. Irgendwelche Ideen?

@Falk: Dumme Frage, wie berechne ich, wie schnell die Abfrage läuft? Das 
Pic läuft mit 4MHz.

@Peter: Diesen Code habe ich jetzt noch nicht ausprobiert.

Danke an alle.

Gruss
Martin

Zu große Cs verwischen die Flanken zu stark, probiere mal kleinere 
(10nF). Wenn´s dann nicht geht, ist es ein anderes Problem. Haste ´nen 
Scope da, um mal die Flanken und eventuelle Preller zu sehen?

Ich habe etwas rumprobiert und festgestellt, dass es hilft, wenn ich die 
Routine folgendermassen anpasse (alte Version siehe ganz oben):

'read encoder
        new_state = (portc & %11000000)
        if (new_state ^ last_cnt) = %11000000 then
            if (new_state ^ last_state) = %10000000 then
                'down
                updown = 0
            elseif (new_state ^ last_state) = %01000000 then
                'up
                updown = 1
            endif
            last_cnt = new_state
            if updown = 1 then 'go up
                'aufwärts
            else 'go down
                'abwärts
            endif
        endif
        last_state = new_state

Jetzt funktioniert es in beiden Richtungen gleich gut (oder gleich 
schlecht), es kommt jetzt vor, dass wenn man den Encoder dreht erst 
einige Schritte in die falsche Richtung gezählt werden, dann die 
Richtung ändert und richtig rum gezählt wird.

@Travel Rec, @Falk: Scope habe ich, konnte das aber noch nicht machen, 
auch nicht mit den anderen Cs.

Gruss
Martin