Prelldauer bei Encoder (Drehimulsgeber)

[Gerald Oppen]

Falk Brunner schrieb:

"Gerald Oppen" <Gerald.Oppen@web.de> schrieb im Newsbeitrag
news:3k25huFrprrbU1@individual.net...


Wenn man zum Zeitpunkt der Flankenwechsels vom A-Signal das B-Signal
abtastet(und entprellt) erhält man einen 2bit Gray-Code.


[ ] Du hast den Unterschied zwischen der Billiglösung und dem richtigen
Dekoder verstanden.

Dann schreib doch bitte mal wie Du es mit gegebener Hardware und ohne
interruptfähigen Eingang besser machen würdest - der uC muss nebenbei
auch noch einiges anderes erledigen...

Gerald

 

[Falk Brunner]

"Gerald Oppen" <Gerald.Oppen@web.de> schrieb im Newsbeitrag
news:3k2ecoFs1kbmU1@individual.net...

Wenn man zum Zeitpunkt der Flankenwechsels vom A-Signal das B-Signal
abtastet(und entprellt) erhält man einen 2bit Gray-Code.


[ ] Du hast den Unterschied zwischen der Billiglösung und dem
richtigen
Dekoder verstanden.

Dann schreib doch bitte mal wie Du es mit gegebener Hardware und ohne
interruptfähigen Eingang besser machen würdest - der uC muss nebenbei
auch noch einiges anderes erledigen...

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

 

[Gerald Oppen]

Falk Brunner schrieb:

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"

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.

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).
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 _______________ ________________
_________| |__________________| |________

->||<- t

.... und mir keiner eine Angabe machen kann bzw. Garantieren will dass
das Prellen von Signal A unter keinen Umständen länger als "t" dauert.
Nach t ist es zu spät um B einzulesen....

Gerald

 

[Michael Schöberl]

Nein! Ich taste mit konstanter Frequenz (Timerinterrupt) ab (mit
Entprellung).

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

 

[Michael Schöberl]

"- 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.

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

 

[Michael Schöberl]

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.

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 ...

Sondern so:

B __ __
_______| |________________________________| |_______________________

A _______________ ________________
_________| |__________________| |________

->||<- t

.... und mir keiner eine Angabe machen kann bzw. Garantieren will dass
das Prellen von Signal A unter keinen Umständen länger als "t" dauert.
Nach t ist es zu spät um B einzulesen....

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

 

[Axel Schwenke]

Gerald Oppen <Gerald.Oppen@web.de> wrote:

Falk Brunner schrieb:
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"

So mache ich es ja auch - fast! Den ohne entprellen geht es nicht

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

 

[Ingo]

Hallo Gerald,

"Gerald Oppen" <Gerald.Oppen@web.de> schrieb im Newsbeitrag
news:3k24v5Fs83tuU1@individual.net...

Ingo schrieb:

Hmm, mal den Gedanken gehabt, evtl. zu messen?
Im Zeitalter digitaler Scope mit massig Triggermöglichkeiten
sollte die Prelldauer doch schnell ermittelt sein...

Grrr... klar habe ich das(und gemacht).
Aber garantierst Du mit dem Messergebniss von zwei Exemplaren die
Funktion über die gesammte Serie während der gesamten (spezifizierten)
Lebensdauer?

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

 

[Falk Brunner]

"Gerald Oppen" <Gerald.Oppen@web.de> schrieb im Newsbeitrag
news:3k2uhvFs589lU1@individual.net...

So mache ich es ja auch - fast! Den ohne entprellen geht es nicht, sonst

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

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

???
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).

Interruptaufruf erfolgt die Abtastung natürlich schon.

Striche/Umdrehung, macht 40 Codes/Umdrehung, macht 25 ms/Code bei 1 U/s,
mal
so als Orientierung).
32Flankenwechsel/ Umdrehung. Mit einem Fingerschnipp kommt man da
schnell in den Grenzbereich bei 1ms Abtastung.

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)

... und mir keiner eine Angabe machen kann bzw. Garantieren will dass
das Prellen von Signal A unter keinen Umständen länger als "t" dauert.
Nach t ist es zu spät um B einzulesen....

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

 

[Gerald Oppen]

Hallo Ingo!

Ingo schrieb:

Grrr... klar habe ich das(und gemacht).
Aber garantierst Du mit dem Messergebniss von zwei Exemplaren die
Funktion über die gesammte Serie während der gesamten (spezifizierten)
Lebensdauer?


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....

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

Gerald

 

[Gerald Oppen]

Michael Schöberl schrieb:

"- 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.


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!

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

Gerald

 

[R. Bombach]

Uwe Hercksen wrote:

es gibt auch Patienten die einen Herzschrittmacher haben weil ihr Herz
ohne zu langsam schlagen würde. Es gibt auch Demand Herzschrittmacher,
die greifen nur ein wenn das Herz zu langsam schlägt.
Ein Ausfall des Herzschrittmachers muß nicht gleich einen Herzstillstand
bedeuten.

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

 

[Alex Wenger]

Hi,

Gerald Oppen wrote:

Digital habe ich den ja drin- aber auf was parametrieren wenn die
Hersteller nur die Prellzeit für 60 Umdrehungen/Sekunde angeben?
Bei meinen Messungen lag ich immer weit unterhalb der angegeben Werten
bei allen manuell erreichbaren Drehzahlen - aber wie sieht es bei
Alterung und Exemplarstreuung aus?
Je Niederfrequenter ich den Filter mach um so mehr gehen mir bei
höheren Drehzahlen Impulse veloren.

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

 

[Martin]

Am Mon, 18 Jul 2005 02:02:52 +0200 schrieb Hartmut Schaefer
<Hartmut.Schaefer@hartmut-schaefer.de>:

Hallo Dschen,

Hast Du blinde oder stark fehlsichtige Nutzer? Die werden sich für so
eine Bedienoberfläche bedanken.

naja, denen wuerde ich die Bedienung der Geraete allgemein dann nicht
empfehlen (Schleifmaschinen).

Nachdem es Mitte der 90er Jahre sehr hip war alle Einstellungen an
Geräten per Endlos-Drehgeber (ohne tastbare Rastung und - viel schlimmer
- Einstellunserkennung) zu erledingen, hat sich das mittlerweile
geändert. Selbst Dreh-Bedienungsknöpfe an Videorecordern haben eine
Mittelstellung und unterschiedlichen Gegendruck (per Feder, analog zur
gewählten Bandgeschwindigkeit).

Je nach Anwendung und Zielgruppe mag es bessere Loesungen als einen
Drehgeber geben (wobei ich die ohne Rastung auch nicht leiden kann),
aber fuer meine Anwendung finde ich sie gut. Ich drehe lieber ein
bisschen, als 20x auf die gleiche Taste zu druecken.

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

 

[MaWin]

"Martin" <martin.lenz@gmx.at> schrieb im Newsbeitrag
newspsvxk9vqr8lri9x@news.gmx.at...

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?

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.