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?
> Und durch den Graycode ist auch eine verspäte Abtastung nicht hochdramtisch...
Wo siehst du da einen Graycode?
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.
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.
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
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.
Angehängte Dateien:
-
jitter.png
8,8 KB
ü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?
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.
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
>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
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.
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
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.
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.