Forum: Mikrocontroller und Digitale Elektronik Prelleffekte bei inkrementalen Drehgebern behandeln


von luke (Gast)


Lesenswert?

Hallo, es geht um die Auswertung der Position maschinenbetriebenen 
optischen inkrementalen Drehgeber. Hier entstehen Prell/pendeleffekte ja 
in der Regel "nur" durch Vibrationen oder mechanischem Spiel im Antrieb.

Wenn die Auswertung nur in einer Drehrichtung erfolgt ist die Sache ja 
ganz klar: Es gibt pro Teilungsperiode des Drehgebers 4 definierte 
Zustände (Flanken der zwei um 90 Grad versetzten Rechtecksignale). der 
Zähler muss daher so programmiert werden, dass nach Abtastung eines 
Zustands nur der entsprechend nächste erlaubte Zustand eine 
Weiterzählung ermöglichen darf. Und durch den Graycode ist auch eine 
verspäte Abtastung nicht hochdramtisch...

Wie sieht es jetzt aber aus, wenn der Zähler für beide Drehrichtungen so 
ausgelegt ist, dass er für eine Richtung hochzählt und in der anderen 
runterzählt?

Wenn dann ein Prellefekt in einer Richtung auftritt, wird die Software 
das zunächst als Richtungswechsel interpretieren und im Besten Fall 
durch Runter+Wieder Hochzählen wieder einen Ausgleich erschaffen. Was 
ist aber, wenn es eine ungerade Anzahl an prellenden Flankenwechseln 
gibt? Dann würde der Zähler hinterher um 1 ungenau laufen.. wie kann man 
das vermeiden?

von Bürovorsteher (Gast)


Lesenswert?

> Und durch den Graycode ist auch eine verspäte Abtastung nicht hochdramtisch...

Wo siehst du da einen Graycode?

von Falk B. (falk)


Lesenswert?

luke schrieb:

> Wenn die Auswertung nur in einer Drehrichtung erfolgt ist die Sache ja
> ganz klar: Es gibt pro Teilungsperiode des Drehgebers 4 definierte
> Zustände (Flanken der zwei um 90 Grad versetzten Rechtecksignale). der
> Zähler muss daher so programmiert werden, dass nach Abtastung eines
> Zustands nur der entsprechend nächste erlaubte Zustand eine
> Weiterzählung ermöglichen darf.

Nö, denn dann würde sich der Zähler verschlucken. Man kann das zwar mehr 
oder minder intelligent filtern, aber der grudnlegende Zähler muss auch 
die Pendelschritte in die falsche Richtung mitmachen.

> Und durch den Graycode ist auch eine
> verspäte Abtastung nicht hochdramtisch...

Naja, soo einfach ist es nicht. Die Abtastfrequenz muss schon 
ausreichend hoch sein.

> Wie sieht es jetzt aber aus, wenn der Zähler für beide Drehrichtungen so
> ausgelegt ist, dass er für eine Richtung hochzählt und in der anderen
> runterzählt?

Das ist der Normalfall.

> Wenn dann ein Prellefekt in einer Richtung auftritt, wird die Software
> das zunächst als Richtungswechsel interpretieren und im Besten Fall
> durch Runter+Wieder Hochzählen wieder einen Ausgleich erschaffen.

Genau.

> Was
> ist aber, wenn es eine ungerade Anzahl an prellenden Flankenwechseln
> gibt? Dann würde der Zähler hinterher um 1 ungenau laufen..

Nö, denn dann wäre deine Abtastfrequenz zu klein. Das Prellen kann zwar 
hochfrequenter sein als die Normalbewegung, aber diese hat eine max. 
Geschwindigkeit, welche durch eine ausreichende Abtastrate erfaßt werden 
muß. Dann paßt das auch mit dem Gray-Code.

> wie kann man
> das vermeiden?

Siehe oben.

von Peter D. (peda)


Lesenswert?

Die Abtastrate muß so hoch sein, daß kein echter Flankenwechsel verloren 
geht.
Vibrationen dürfen schneller sein. Sie treten ja nur direkt an den 
Stellen eines Flankenwechsels auf. D.h. bis zur nächsten echten Flanke 
ist genügend Zeitabstand.

von Michael B. (laberkopp)


Lesenswert?

luke schrieb:
> Wenn dann ein Prellefekt in einer Richtung auftritt, wird die Software
> das zunächst als Richtungswechsel interpretieren und im Besten Fall
> durch Runter+Wieder Hochzählen wieder einen Ausgleich erschaffen.

Du hast offenkundig die richtige Auswertung von Incremetalgebern nicht 
verstanden. Es werden keine Flanken ausgewertet. Mit korrektem 
Auswerteverfahren hat man keinen störenden Effekt durch Prellen.

http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29

von luke (Gast)


Lesenswert?

Michael B. schrieb:
> Du hast offenkundig die richtige Auswertung von Incremetalgebern nicht
> verstanden. Es werden keine Flanken ausgewertet. Mit korrektem
> Auswerteverfahren hat man keinen störenden Effekt durch Prellen.

Da steht doch auch genau das drin, was ich meinte. Auf den 1. Zustand 
muss der 2. folgen, danach der 3. und erst dann der 4.

von luke (Gast)


Angehängte Dateien:

Lesenswert?

übrigens macht der Timer des  Mikrocontrollers das schon genau so, wie 
ich es hier beschrieben habe. Also was soll an der Richtungsauswertung 
denn falsch sein?

von Michael B. (laberkopp)


Lesenswert?

luke schrieb:
> Da steht doch auch genau das drin, was ich meinte.

Nein. Du hast schlimmerweise nicht mal den Unterschied bemerkt.

Eine wie beschrieben richtige Auswertung hat kein Problem mit Prellen.

von luke (Gast)


Lesenswert?

Du bist ja eine sehr große Hilfe... wenn man einen Drehrichtungswechsel 
berücksichtigt, ist doch klar, dass die Zustandsreihenfolge nicht mehr 
dem festen Schema entsprechen kann, das für die Auswertung von nur einer 
Drehrichtung gilt

von Venkman (Gast)


Lesenswert?

>Es muss sichergestellt sein, dass bei voller Drehzahl jeder der vier >Zustände 
erkannt werden kann. D.h. die Abtastrate muss mindestens viermal so >groß sein, 
wie die Signalfrequenz einer Spur

Ist das denn richtig? Sollte nicht jeder Zustand zweimal abgetastet 
werden? Wenn ich bei der Abtastung einmal jeden Zustand erwische und das 
liegt in Richtung prellende Flanken kann es ja passieren, dass ich einen 
Zustand doppelt erwische und dann einen verliere.

Ich bin kein ascii-Künstler, daher mal so, der binär-Strich wäre die 
Abtastung


    |    |    |
11111111 1      11111111        11111111
        0x000000        00000000        00000000


    11111111        11111111        11111111
0000        00000000        00000000        00000000

Wenn ich so wie in dem Artikel abtaste passiert an der gezeichneten 
Stelle doch folgendes:

AB
AB
ab

anstatt

AB
aB
ab

von Teo D. (teoderix)


Lesenswert?

Venkman schrieb:
> das
> liegt in Richtung prellende Flanken kann es ja passieren, dass ich einen
> Zustand doppelt erwische und dann einen verliere.

Dem GrayCode ist es nun mal eigen, das dies dann nur zwischen dem alten 
und dem neuen Zustand pendeln kann. Verloren geht also nur was, wenn du 
zu langsam abtastest.
Ist halt nur die Frage, ob du dieses Pendeln an deine Steuerung 
ungefiltert weitergeben kannst/willst.

von georg (Gast)


Lesenswert?

luke schrieb:
> wenn man einen Drehrichtungswechsel
> berücksichtigt, ist doch klar, dass die Zustandsreihenfolge nicht mehr
> dem festen Schema entsprechen kann

Natürlich tut sie das, der Zähler zählt in einer Richtung 1-2-3-4, in 
der andern 1-4-3-2. Also kann auf die 1 je nach Richtung nur 2 oder 4 
folgen.

Georg

von Yalu X. (yalu) (Moderator)


Lesenswert?

luke schrieb:
> Wenn dann ein Prellefekt in einer Richtung auftritt, wird die Software
> das zunächst als Richtungswechsel interpretieren und im Besten Fall
> durch Runter+Wieder Hochzählen wieder einen Ausgleich erschaffen. Was
> ist aber, wenn es eine ungerade Anzahl an prellenden Flankenwechseln
> gibt? Dann würde der Zähler hinterher um 1 ungenau laufen.. wie kann man
> das vermeiden?

Wenn eines der beiden Abtastsysteme genau auf einer Flanke steht, kann
es zum Hin- und Herpendeln des Zählerstands um eine Einheit kommen. Das
stört aber normalerweise nicht, den derselbe Effekt kann ja auch
auftreten, wenn die Welle tatsächlich etwas vibriert.

Wichtig ist nur, dass zwischen zwei Flanken, wo die beiden Signale
eindeutig high oder low sind, der richtige Wert ausgegeben wird. Das ist
bei korrekt implementiertem Auswerteverfahren aber auch immer der Fall.

Deswegen ist das von dir vermutete Problem in Wirklichkeit gar keines.

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
Noch kein Account? Hier anmelden.