Encoder lesen, Problem mit Code

[Martin G. (hb9tzw)]

Ciao zusammen

Ich versuche einen Encoder zu lesen, einen der nur bei 00 und 11 rastet. 
Dieser Thread

Beitrag "Drehimpulsgeber mit Rasterstellung bei 00/11 auswerten"

hat dabei geholfen. Ich haben den dort vorgeschlagenen C-Code für AVR

static uint8_t last_state = 0;
static uint8_t last_cnt = 0;
uint8_t new_state;

new_state=PINE & (_BV(PINE4) | _BV(PINE3));
if ((new_state^last_cnt)==(_BV(PINE4) | _BV(PINE3)) )
{
  if ((new_state ^ last_state)==_BV(PINE4))
    enc_delta+=1;
  else
    enc_delta-=1;
  last_cnt=new_state;
}
last_state=new_state;

in Picbasic zu übersetzen versucht, und dabei ist das herausgekommen:

'im Kopf der Datei
dim last_state as byte
last_state = 0
dim last_cnt as byte
last_cnt = 0
dim new_state as byte

'im main-Loop
new_state = (PORTC & %11000000)
if (new_state ^ last_cnt) = %11000000 then
   if (new_state ^ last_state) = %10000000 then
      'down
   else
      'up
   endif
   last_cnt = new_state
endif
last_state = new_state

Dies zählt mir auch recht gut nach oben (rechtsrum), beim Runterzählen 
(linksrum) herrscht jedoch das Chaos. Mal wird nach unten gezählt, mal 
nach oben, mal wird einige Male zwischen zwei Werten hin und her 
gewechselt.

Sieht irgendwer den Fehler? Im Moment bin ich ratlos. Wahrscheinlich 
habe ich etwas falsch übersetzt, weil ich bisher noch nie viel mit C zu 
tun hatte.

Danke euch.

Gruss
Martin

[Knut B. (Firma: TravelRec.) (travelrec)]

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

[Martin G. (hb9tzw)]

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

[Knut B. (Firma: TravelRec.) (travelrec)]

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.

[Martin G. (hb9tzw)]

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

[Knut B. (Firma: TravelRec.) (travelrec)]

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.

[Martin G. (hb9tzw)]

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

[Falk (Gast)]

@ Martin Geissmann

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

Wie schnell ist den PIC Basic? Die Abfrage des Encoders sollte so mit 
100..500 Hz laufen. Sonst verschluckt sie Schritte.

MfG
Falk

[Peter D. (peda)]

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

[Martin G. (hb9tzw)]

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

[Knut B. (Firma: TravelRec.) (travelrec)]

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?

[Falk (Gast)]

@Martin Geissmann

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

Mit PIC Basic kenn ich mich nicht aus. Das wirst du ausprobieren müssen. 
In deiner Schleife musst du dazu immer ein freies Pin toggeln. Das 
kannst du dann mit einem einfachen Frequenzzähler oder Oszilloscop 
messen.

MFG
Falk

[Martin G. (hb9tzw)]

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

[Uwe (Gast)]

Hi!
Mal eine blöde Frage, erzeugt dein Encoder nun saubere Impulse oder 
nicht?
Das encoder.jpg sieht jedenfalls gut aus. Wenn du das gemessen hast ist 
dein Code Mist, wenn nicht musst du besser entprellen.
Industrieencoder musst du eigentlich überhaupt nicht entprellen.
Viel Erfolg, Uwe

[Falk (Gast)]

@Uwe

>Das encoder.jpg sieht jedenfalls gut aus. Wenn du das gemessen hast ist
>dein Code Mist, wenn nicht musst du besser entprellen.

Die richtige Software entprellt das automatisch. Keine Notwendigkeit mit 
RC Gliedern noch rumzumachen.

MFG
Falk

[Uwe (Gast)]

Hi!
@Falk
 Einen richtigen Encoder musst du überhauptnicht entprellen, es kann 
sogar schädlich sein wenn du hohe Geschwindigkeiten hast.

MFG Uwe

[Falk (Gast)]

@Uwe

> Einen richtigen Encoder musst du überhauptnicht entprellen, es kann
> sogar schädlich sein wenn du hohe Geschwindigkeiten hast.

Das hatten wir doch schon mal. Sehr ausschweifend! ;-)

MfG
Falk

[Uwe (Gast)]

Hi!
@Falk
ja , kenne ich, spreche aber aus eigener Erfahrung. OK,
10-Bitinterpolation habe ich noch nicht gemacht, und halte ich auch 
nicht für unbedingt sinnvoll, ja geht natürlich, Dreck und Temp. tun 
dann aber ihr übriges. Richtige Schirmung und Signalübertragung sind da 
wichtiger.
(Ich kenne mich aber nur mit Antrieben bis 15KW und 1G aus.)

MFG Uwe