Prelldauer bei Encoder (Drehimulsgeber)

"Gerald Oppen" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

richtigen

Schon klar. Aber die Lösung wurde bereits auf dem Silbertablett serviert.

"- Zustandsgesteuert: die Ports werden *synchron* abgetastet. Eine Statemachine bestimmt dann die Richtung (siehe faq) - keine Probleme mit dem Prellen, üblicherweise passiert die Auswertung im Timerinterrupt"

Du kannst praktisch jeden schon verfügbaren Timerinterrupt nehmen den du hast. Du kannst sogar in irgendwelchen Hauptprogrammschleifen, die keine äquidistante Abtastung garantieren das machen. Hauptsache du tastest hinreichend schnell ab (will sagen, der User darf nicht schneller drehen als die Software Codewechsel sehen kann). Aber wenn du z.B. einen 1ms timer (oder Hauptschleife) hast, muss der User schon tierisch "am Rad drehen" um schneller zu sein als die Software (Ich denke mal du hast max 10 Striche/Umdrehung, macht 40 Codes/Umdrehung, macht 25 ms/Code bei 1 U/s, mal so als Orientierung). Und das ganze kostet eine Handvoll Zeilen Assembler, selbst der langsamste

8051 muss dafür nicht mehr als 1% seiner Rechenleistung verbraten. (bissel OFFTOPIC, ich hab vor Urzeiten mal ne 8fach LED-MUX mit nem 68HC11 gebaut und die Rechenzeit im Timerinterrupt gemessen, ca. 1% bei 8 MHz Quarz =2 MHz Systemtakt ~ 700 kHz Maschinentakt).

MfG Falk

Falk Brunner schrieb:

So mache ich es ja auch - fast! Den ohne entprellen geht es nicht, sonst bekommt man doch im Grenzbereich eventuell die falsche Richtung decodiert. Da das prellen nicht synchron stattfindet macht auch ein 100% synchrones Abtasten keinen Sinn - im Gegenteil, da könnte man sich zusätzliche Probleme durchs übersprechen einhandeln.Im gleichen Interruptaufruf erfolgt die Abtastung natürlich schon.

32Flankenwechsel/ Umdrehung. Mit einem Fingerschnipp kommt man da schnell in den Grenzbereich bei 1ms Abtastung.

Mein Problem ist aber das bei langsamer Umdrehung nicht so schön symetrisch aussieht:

B _______________ ________________ _________| |__________________| |________

A _______________ __________________ ________________| |__________________|

Sondern so:

B __ __ _______| |________________________________| |_______________________

A _______________ ________________ _________| |__________________| |________

->||

okay - das klingt solide ... aber "Entprellung"?

aber der ganze Trick an dieser Gray Sache war doch, dass es eben *ohne* Entprellung geht!

Beispiel: wir stehen am Übergang, A=1 und B zappelt hin und her (beliebig schnell)

hier noch die Zustände:

Zustands NR 0 1 2 3 A 0 0 1 1 B 0 1 1 0

wir sind also nun einfach mal in Zustand 1

- Abtastung ergibt nun z.B. A=1, B=1 ... also weiter nach Zustand 2, Zäher um 1 erhöhen

- nächste Abtastung A=1 B=0 ... zurück nach Zustand 1, Zähler um 1 veringern

- nächste Abtastung A=1 B=0 ... wir bleiben im Zustand, Zähler unverändert

was nicht passieren darf:

- von Zustand 1 nach 3 ... wir wissen nicht, ob es +2 oder -2 war, die Abtastungen waren zu langsam bzw. der Knopf wurde zu schnell gedreht

Anmerkungen:

- wie du richtig erkannt hast, wird der Decoder da einen Drehrichtungswechsel erkennen (sogar mehrere) ... ist allerdings kein Wunder, da unser Geber ja gerade auch auf der Kippe steht!

- es ist eine reine Zustandsauswertung (ohne irgendwo Flanken abzuleiten!)

- wenn nun im timer Interrupt A und B nacheinander abgetastet werden, dann führt das dazu, dass sich die Maximalgeschwindigkeiten für beide Richtungen minimal unterscheiden (nicht wirklich schlimm) - synchrone Abtastung wär aber optimal

ich hoffe der Unterschied ist nun klar?

bye, Michael

mal ne dumme Idee um die Verwirrung noch zu vergrößern ... man könnte auch beide Ports (auf beiden Flanken) interrupts auslösen lassen und dann synchron abtasten und in die state machine gehen!

spart die Rechenzeit wenn keiner am Rad dreht ;-)

bye, Michael

mit synchron meinte ich Port A und Port B gleichzeitig abtasten (also z.B. mit einem Aufruf in eine interne Variable lesen und dann erst die bits testen). Ein paar Cycles Unterschied machen IMO aber auch nichts aus - es wird sich wohl nur die Maximalgeschwindigkeit für die beiden Drehrichtungen etwas unterscheiden ...

ich glaube mir wird jetzt erst das Problem bewusst ...

Z# 0 1 2 3 B 0 1 1 0 A 0 0 1 1

Beispiel: A=0, B=0 -> Zustand 0 A=0, B=1 -> Zustand 1 - i++ A=1, B=1 -> Zustand 2 - i++ A=0, B=1 -> Zustand 1 - i-- A prellt A=1, B=1 -> Zustand 2 - i++ A prellt A=0, B=1 -> Zustand 1 - i-- A=1, B=0 -> Zustand 3 - ungültiger Übergang, Zähler unverändert

Auswirkung: statt um 2 wurde nur um 1 weitergezählt

um das zu verhindern hast nun eine Softwareentprellung für A und B eingebaut? vom Prinzip also ein Tiefpass? (und woher weisst du Grenzfrequenzen des Prellens?)

Ansätze:

- um wieviel unterscheiden sich denn die Zeiten t_min und t_prell_a_max? vielleicht genügt eine 5x Sicherheitsreserve für Alterung? vielleicht könne man einen Geber künstlich altern und dann immernoch ne Reserve rausmessen? (Wasser rein, einige rpm mit Bohrmaschine ...)

- irgendwo stand, du hattest eine Datenblattangabe für eine Prellzeit bei bestimmter Drehzahl - wird die tatsächlich länger? könnte man die aktuelle Reserver in erster Näherung mal auf worst case Prellen bei geringer Drehzahl runterinterpolieren?

- wenn der Geber wirklich zu schlecht/billig ist ... ungültige Übergänge zählen und bei schlechter werdendem Geber Bedarf für eine Wartung anzeigen?

bye, Michael

Ist das jetzt Lernresistenz?

Wenn du die Signale mit einer Statemachine auswertest, mußt du nix Entprellen. Das Prellen wird wie jeder andere irreguläre Zustands- wechsel eines Signals weggerechnet.

[Diagramm gesnipt]

Wenn die Überlappung tatsächlich so kurz ist wie von dir gezeichnet, dann ist der Encoder *kaputt*. Da hilft dann nur wegwerfen. Weit.

Ich bezweifle das aber.

Eine gewisse Asymmetrie wird von Rastmechanismus stammen, wegen dem die Achse nicht gleichmäßig rund läuft, sondern sozusagen in kleinen Sprüngen. Diesem Problem begegnet man mit einer hinreichend hohen Abtastfrequenz.

Die Prellzeit eines mechanischen Kontakts ist näherungsweise konstant. Zu "übersehenen" Zuständen wegen Prellens kommt es also erst bei höheren Drehzahlen. Eigentlich würde ich eine Angabe a'la "maximale Drehzahl" im Datenblatt des Herstellers erwarten.

XL

Hallo Gerald,

"Gerald Oppen" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

garantieren könnte dies nur der Hersteller. Es wäre aber schon mal ein Anhaltspunkt gewesen. Warum eigendlich nicht optische Inkrementalgeber einsetzen? da prellt nichts....

Gruß Ingo

"Gerald Oppen" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

Knapp danben ist auch vorbei. Ich glaube, du hast denr Trick der State mAchine noch nicht verstanden.

??? Wenn der Encoder prellt, dann nur auf einem Kanal, der andere steht felsenfest. Durch den Gray-Code (und die richtige Auswertung) kann nur ein vor zun zurück springen erkannt werden (wenn es prellt). Die Richtung wird immer richtig erkannt (eben halt vor und zurück).

mal

Dann nützt dir auch eine tierische digitale/analoge Tiefpassfilterung nichts, denn du willst ja scheinbar auch recht hohe Drehfrequenzen erfassen. Die Entprellung von Tastern funktioniert nur, weil das Prellen wesentlich schneller ist (sagen wir mal 10 ms) als die eigentlichen Tastendruchwiederholraten (sagen wir mal 100ms)

Tja, warum wil wohl keiner das GARANTIEREN!! Wieder mal Fall von eierlender Wollmilchsau. Wenn's halt wirklich GARANTIERT werden soll, muss ein anderer Geber her. Basta.

MFG Falk

Hallo Ingo!

Ingo schrieb:

Weil die Teile gottgegeben sind und ich das nicht ändern kann!

Gerald

Michael Schöberl schrieb:

Geht nicht, da kommt was falsches raus wegen dem asymetrischen Signalbild. Und Interrupts habe ich nicht zur Verfügung.

Gerald

Es gibt auch grosse Herzschrittmacher, welche on-demand defibrillieren können. Ich hab mal einen Bericht eines amerikanischen Patienten gelesen, dessen solcher Schrittmacher während der gewöhnlichen Büroarbeit aus unersichtlichen Gründen auf die Idee kam, mal kurz zu defibrilliern. Er wolle dies nicht noch mal haben, war so ungefähr die Kernaussage. Es muss ihn ziemlich rumgeschleudert haben, aber der Schreck-Effekt sei noch unangenehmer gewesen.

--
mfg Rolf Bombach

dann machs so niederfrequent wie du gerade noch damit leben kannst, mehr kannst du eh nicht tun und wenn die tatsächliche Prellzeit darunter liegt ists auch nicht schlimm.

-Alex

Am Mon, 18 Jul 2005 02:02:52 +0200 schrieb Hartmut Schaefer :

Schlimm sind Drehgeber, die nur jede 2. (oder n te) Rastung auswerten. So ein Ding haben sie in meiner Mikrowelle verbaut - wofür dann überhaupt Rastungen?

--
Martin

"Martin" schrieb im Newsbeitrag news: snipped-for-privacy@news.gmx.at...

Vielleicht ist das ein richtiger Drehgeber (je Raste anderes Signal) der mit der unbrauchbaren Schaltung um die es hier im Thread geht (Signal A Takt, Signal B Daten) arbeitet und nur bei jeder steigenden Flanke schaltet.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.