Forum: Mikrocontroller und Digitale Elektronik Prelleffekte bei inkrementalen Drehgebern behandeln


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von luke (Gast)


Bewertung
-1 lesenswert
nicht 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)


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

Wo siehst du da einen Graycode?

von Falk B. (falk)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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:

Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
-2 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.