Hi,
nachdem mein anderer Faden zu Drehgebern ja leicht abgedriftet ist, aber
teilweise zumindest durchaus informativ war, hier jetzt ein weiterer.
Das Thema ist aber ein bisschen ein anderes, deswegen auch ein neuer
Faden. Und zwar will ich einen Drehgeber an einen Raspberry Pi
anschließen, um damit die Lautstärke zu regeln (per Hand versteht sich).
Jetzt gibt es bei reichelt mehrere Varianten dieser Teile:
- einige haben doppelt so viele Rastungen, wie Impulse, andere gleich
viele. Muss ich dann im ersten Fall 2x weiter drehen, um eine Änderung
des Signals zu erhalten?
- bei den STEC12E ist (lt. Datenblatt) der Rastpunkt auf der Flanke, bei
den STEC11B nicht. Hat das eine Vorteile?
Was ich will, ist ein Drehgeber, der sich möglichst einfach auswerten
lässt. Welche der 4 Kombinationsmöglichkeiten der beiden Varianten wäre
wohl die am besten geeignete und warum?
http://www.reichelt.de/index.html?ACTION=2;GROUPID=3714;SEARCH=Drehimpulsgeber
Viele Grüße
Sven schrieb:> Muss ich dann im ersten Fall 2x weiter drehen, um eine Änderung des> Signals zu erhalten?
Mach eine Dynamik in den Geber. Dann ändert er sich schneller, wenn du
schneller drehst (so ähnlich wie die "Beschleunigung" beim Mauszeiger).
Das "fühlt" sich richtig gut an.
Siehe http://www.lothar-miller.de/s9y/categories/54-Encoder
Sven schrieb:> - einige haben doppelt so viele Rastungen, wie Impulse, andere gleich> viele. Muss ich dann im ersten Fall 2x weiter drehen, um eine Änderung> des Signals zu erhalten?
Nein. Das muss aber anders ausgewertet werden.
Sven schrieb:> Was ich will, ist ein Drehgeber, der sich möglichst einfach auswerten> lässt.
Das ist keine Raketentechnik. Die lassen sich alle einfach auswerten.
Kleiner Tip:
http://stores.ebay.de/Logo-s-Elektronik-Kiste/Encoder-inkremental-/_i.html?_fsub=366805719
Obwohl der obere von Reichelt, der mit dem LED-Kranz, der hat natürlich
was.
Sven schrieb:> Joa... Und welchen Drehgeber nehm ich am besten dafür?
Für einen Lautstärkesteller würde ich einen mit feiner Rastung
bevorzugen. Also 24/24 oder so.
mfg.
Sven schrieb:> Und zum zweiten Problem? Rastung auf der Flanke oder dem Pegel?
Einer ordentlichen Auswertung ist das egal. Aber viele Leute fluchen rum
über die Rastung auf der Flanke.
mfg.
Sven schrieb:> Wie sieht denn deiner Meinung nach eine ordentliche Auswertung aus?> Endlosschleife oder per Interrupt?
Diese Diskussion hatten wir doch nun lange genug.
Wenn eine Flanke auf der Rastung liegt, ist es einfach nicht sinnvoll,
die beiden sich daraus ergebenden Zustände zu unterscheiden.
Normalerweise erwartet man von einem Drehregler, dass er pro Rastung
eine Zustandsänderung macht.
Max M. schrieb:> Sven schrieb:>> Endlosschleife oder per Interrupt?>> Und los gehts...
Nein, jetzt mal ernsthaft. Kann mir mal einer Vor-/Nachteile nennen? Ich
will einfach so ein Ding und mit möglichst wenig Umständen und Fluchen
die Auswertung hinkriegen. Aber jeder macht voll das Geheimnis um seine
Auswertung und anstatt was zu erklären, wird nur geflamed. Das ist doch
scheiße
Sven schrieb:> Wie sieht denn deiner Meinung nach eine ordentliche Auswertung> aus?> Endlosschleife oder per Interrupt?
Weder noch.
Ich verwende Polling. 1000 Mal pro Sekunde abfragen. Aber ich denke, das
meinst du auch mit Endlosschleife. Andere sind der Meinung, dass es mit
Interrupt besser geht. Ist mir egal. Ich lass mich da auf keine
Diskussionen mehr ein. Das führt zu nichts. Da kann man auch gleich mit
den Zeugen Jehovas über den Urknall oder die Evolution diskutieren.
Aber das ist nur die eine Hälfte. Die Auswerung muss sicherstellen, dass
der ganze Weg gemacht wurde.
Also 11 - 10 - 00 - 01 - 11
Bei einer 12/24 muss der ganze Weg von 11 bis 11 ausgewertet werden und
das Weiterzählen erfolgt, wenn er beim zweiten 11 drauf ist. Sämtliches
Hin- und Hergewackel dazwischen darf ihn dabei nicht aus der Ruhe
bringen. Bei einem 24/24 ist die Rastung auf 11 und 00. Dann wird auch
bei 00 gezählt.
Oder er rastet auf dem Flankenwechsel bei 01 bzw. 10. Dann wird eben da
gezählt.
mfg.
Sven schrieb:> wird nur geflamed. Das ist doch> scheiße
Und deswegen wollte ich eigendlich nichts mehr dazu schreiben.
Meine Meinung: Interrupt!
1. Genau für Sowas wurde das von den MC-Herstellern implementiert.
2. Der MC hat normalerweise was besseres zu tun als sinlos Eingänge zu
pollen.
Und häng eine R/C-Kombination zur entprellungzwischen Drehgeber und
MC-Eingang. Dann muss der MC damit nicht sinnlos zZeit verplempern.
Hmm... 1000x pro Sekunde ist schon heftig. Das Programm
import time
while True:
time.sleep(0.001)
verursacht bei mir eine dauerhafte CPU-Last von ca. 8%. Dafür, dass der
Drehgeber wohl nicht so oft gedreht wird, ist mir das eigentlich
unangenehm viel.
@jens2001:
Hört sich an, als hättest du sowas schonmal per Interrupt umgesetzt.
Kannst du ein wenig konkreter werden oder mich auf ein Tutorial
verweisen?
Sven schrieb:> verursacht bei mir eine dauerhafte CPU-Last von ca. 8%. Dafür, dass der> Drehgeber wohl nicht so oft gedreht wird
Du hast das Problem beim pollen genau erkannt!
Sven schrieb:> Was ich will, ist ein Drehgeber, der sich möglichst einfach auswerten> lässtSven schrieb:> Und zum zweiten Problem? Rastung auf der Flanke oder dem Pegel?Sven schrieb:> Joa... Und welchen Drehgeber nehm ich am besten dafür?
Es ist egal, nimm den, der dir mechanisch am besten passt. In Software
kann man das Verhalten anpassen, durch 2 teilen und damit Zustände am
Flankenwechsel ignorieren.
EIGENTLICH will man Lautstärke nicht durch mehrfaches rumkurbeln
einstellen, sondern durch eine Drehbewegung von 270 Grad, und dann
sollte er 255 Positionen haben, also würde ich statt Drehgebern mit 32
oder 64 Rastungen nach welchen mit 360 Rastungen suchen.
Die von Lothar gepostete Beschleunigungsauswertung ist sinnvoll
http://www.lothar-miller.de/s9y/categories/54-Encoder
bei Drehgebern die 2 Impuls pro Rastung (und einen davon auf der
Rastung) liefern muss man enc_ab an der passenden Stelle durch 2 teilen.
Ich würde (bei 16 Rastungen) den nehmen
http://www.pollin.de/shop/dt/Njg2OTU3OTk-/Bauelemente_Bauteile/Passive_Bauelemente/Potis_Trimmer_Encoder/Encoder_PANASONIC_EVEQDBRL416B.html
der ist billig und hat sogar eine Tastfunktion (draufdrücken).
Millionen von Drehbewegungen muss er ja nicht aushalten.
Ein grösserer Knopf wäre sinnvoll.
Hallo,
ich habe meine Implementierung auf Basis des Codes von
Peter Danneggers C Programm für die Drehencoder Dekodierung in
einer Hochsprache als assembleroptierte Version in eine Bibliothek
gepackt und hier beschrieben:
Beitrag "Re: Drehimpulsgeber"
In der worst-case Analyse benötigt die Routine 119 CPU-Takte + 3
CPU-Takte (ISR-Call) - also 123 CPU-Takte.
Wird der AVR µC mit z.B. 16MHz betrieben und mit einer
Timer-Zyklusfrequenz von 2kHz ! betrieben, erfolgt ein Aufruf der
Timer-ISR alle 16.000kHz /2kHz = 8.000 CPU-Takte.
In diesem Timer-Zyklus beträgt dann die µC Auslastung nur 1,54%.
Sven schrieb:> Hmm... 1000x pro Sekunde ist schon heftig. Das Programm>> import time> while True:> time.sleep(0.001)>> verursacht bei mir eine dauerhafte CPU-Last von ca. 8%. Dafür, dass der> Drehgeber wohl nicht so oft gedreht wird, ist mir das eigentlich> unangenehm viel.
Michael B. schrieb:> bei Drehgebern die 2 Impuls pro Rastung (und einen davon auf der> Rastung) liefern muss man enc_ab an der passenden Stelle durch 2 teilen.
Drehgeber die 2 Impulse pro Rastung haben? Ich finde immer nur die mit
einem oder 1/2...
Hallo,
für mein Verstärkerprojekt habe ich auch Drehgeber für alle
Einstellmöglichkeiten wie Lautstärke, Balance, Kanalpegel (z.B. bei
5.1), Klangreglker usw. vorgesehen. Ich habe optische Drehgeber ohne
Rastung mit 64 Vollschritten pro Umdrehung. Ich kann später mal
nachgucken, welche das sind und wo ich die mal gekauft habe, Reichelt
hat die jedenfalls nicht.
Ich werte jede Flanke von beiden Kanälen aus, so daß ich 256 Schritte
pro Umdrehung erhalte. Bei mir läuft eine Interruptroutine, die per
Timer 1000-mal pro Sekunde aufgerufen wird, die ist sehr kurz gehalten
und zählt nur ein paar Zähler als Timer (die für andere Funktionen
gebraucht werden) und fragt die Pins vom Drehgeber ab. Es wird eine
globale Variable (signed int) entsprechend hoch- oder heruntergezählt,
die im Hauptprogramm abgefragt (um wieviele Schritte hat sich der
Drehgeber in welche Richtung bewegt?) und anschließend auf Null gesetzt
wird, beim Nullsetzen wird der Interrupt kurz disabled.
Funktioniert einwandfrei und es werden keine Schritte vermißt. Da z.B.
die Lautstärke in 0.5dB-Schritten geändert wird und es ca. 200 Stufen
gibt, wird mit etwas weniger als eine volle Umdrehung der gesamte
Bereich erfaßt, fast so wie bei einem normalen Poti. Vorteil ist aber,
daß es reprodizierbar, direkt wie ein Poti, aber verschleißfrei ohne
Poti funktioniert. Eine Beschleunigungsfunktion wie z.B. für Mäuse will
ich da nicht haben und brauche die mit dem Drehgeber auch nicht.
Allerdings ist der Drehgeber teurer als die mit Schaltkontakten, dafür
verschleißfrei. In meinem Projekt ist je ein Drehgeber im Verstärker und
in dessen Fernbedienung vorhanden.
Gruß
Andy
m.n. schrieb:> Mit Schrittmotor, Interrupt und Dynamik.> Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR"> Kein Prellen, Pendeln, Flattern, Zwitschern, ...
Wie schon Marek in dem thread schrieb: Als Beispiel, wie man es nicht
machen soll. Da sendet der Arduino 'wie mit 300bd' und m.n. wundert sich
nicht und sucht den Fehler lieber beim Arduinokonzept, als bei sich
selbst.
Obwohl die genannten Schrittmotoren und optischen Encoder (mechanische
Kontakte werden nicht vorgeschlagen) wenigstens von Haus aus nicht
prellen, und die Schaltung mit RC Tiefpass und Schmitt-Trigger Eingängen
Strörungen wegfiltern sollte, bekommt er es trotzdem hin, den Prozessor
mit seinen Flankenwechselinterrupts zu überlasten.
M.N. lernt's nie (aber Schrittmotore gehen schon, wie Sigi's Beitrag
dort zeigt, wenn man es richtig macht).
Sven:
> Hmm... 1000x pro Sekunde ist schon heftig. Das Programm>> import time> while True:> time.sleep(0.001)
Bullshit, du denks als Mensch, und das ist dir zuviel.
Einem µC ist es herzlich egal, wie oft er was macht.
Dein Programm wird Zeit sinnslos in Warteschleifen verbringen. Ohne es
zu kennen: geschätzt 50% der Zeit. Ist bei fast allen hier so.
Und das ist dir nicht zu heftig?
Andreas W. schrieb:> Ich habe optische Drehgeber ohne> Rastung mit 64 Vollschritten pro Umdrehung.
Wenn man sich diese leisten kann, ist man sicherlich gut bedient. Ein
bißchen Dynamik ist aber auch nicht verkehrt: beim ganz langsamen Drehen
wird nichts verändert und bei der Lautstärke kann man feinfühliger
einstellen, als es die Auflösung des Drehgebers vorgibt. Das bedeutet,
eine Änderung erfolgt nicht bei 360/256° sondern bei größerem Winkel.
Speicherst Du den aktuellen Zustand, damit beim Einschalten die alte
Einstellung wieder vorhanden ist?
Oder setzt Du die Lautstärke auf einen kleinen Wert zurück?
Hallo,
die Lautstärke wird beim Einschalten jedesmal auf Null gesetzt, das ist
bei >1000W Gesamtaudioleistung auch zu empfehlen... Alle anderen
Einstellungen sind für jede Quelle getrennt gespeichert und werden beim
Wechsel der Quelle eingestellt. Danach kann man die Einstellungen bei
Bedarf ändern und ggf. neu abspeichern oder eine andere Quelle oder die
gleiche aufrufen, dann bleibt die alte Einstellung erhalten. Die
Lautstärke bleibt beim Quellenwechsel erhalten, dafür kann man für jede
Quelle die Eingangsempfindlichkeit individuell einstellen (wird auch
gespeichert, direkt am analogen XLR-Eingang kann man die auch grob per
Minidrehschalter einstellen).
Das ganze ist schon ein größeres Projekt, in der Fernbedienung ist ein
Arduino Due, im Verstärker ein Raspberry Pi B+. Verarbeitet wird
schließlich digital für bis zu 8 Kanäle, 24 analoge Eingänge (XLR),
beliebig zuzuordnen, 8 analoge Ausgänge (XLR), je 8 digitale Ein- und
Ausgänge je zur Hälfte optisch und Cinch, alles per Software
konfigurierbar. Das ist dann auch gleichzeitig die Steuerzentrale für
mein Heimkino.
Mein alter Vorverstärker aus dem Jahr 1985 hat zwar eine rein analoge
Signalverarbeitung und hat nur zwei Kanäle (Stereo), hat aber auch einen
Drehgeber (auch optisch, selbstgebaut mit Zahnrad aus Leiterplatte und
zwei Gabellichtschranken) und ist prozessorgesteuert, der Z80 läuft also
schon seit 30 Jahren ununterbrochen, abgesehen von einigen
Stromausfällen und zwei Umzügen... Auch da gibt es weder Potis noch
Schalter im Signalweg.
Eine Dynamik im Drehgeber hatte ich auch probiert, konnte mich aber
nicht damit anfreunden, daher flog die wieder raus.
Gruß
Andy
Sven schrieb:> - einige haben doppelt so viele Rastungen, wie Impulse, andere gleich> viele. Muss ich dann im ersten Fall 2x weiter drehen, um eine Änderung> des Signals zu erhalten?
Entscheidend ist die Anzahl der Rastungen. Denn Positionen zwischen den
Rastungen kann (und muß) zwar dein µC mitzählen, nutzen kannst du aber
nur Positionen wo der Drehgeber einrastet.
Und übrigens: "pro Impuls" bedeutet in diesem Zusammenhang "pro Gray-
Zyklus". Die o.g. Drehgeber rasten also entweder auf einem oder auf zwei
der insgesamt 4 Zustände in einem Gray-Zyklus ein.
> - bei den STEC12E ist (lt. Datenblatt) der Rastpunkt auf der Flanke, bei> den STEC11B nicht. Hat das eine Vorteile?
Rastpunkt auf der Flanke bedeutet, daß man in der Praxis damit rechnen
muß auch bei stehendem Encoder laufend Pulse zu bekommen, die (bei
korrekter Auswertung) den Zähler um +/-1 wackeln lassen. Aber da man
durch die Rastung ja ohnehin nur die halbe oder gar viertel Auflösung
hat, ist das nicht schlimm.
> Was ich will, ist ein Drehgeber, der sich möglichst einfach auswerten> lässt. Welche der 4 Kombinationsmöglichkeiten der beiden Varianten wäre> wohl die am besten geeignete und warum?
Die sind alle gleich gut.
Lothar M. schrieb:> Mach eine Dynamik in den Geber. Dann ändert er sich schneller, wenn du> schneller drehst (so ähnlich wie die "Beschleunigung" beim Mauszeiger).
Im Prinzip ja. Allerdings würde ich speziell bei einem Lautstärkeregler
keine Dynamik vorsehen. Einfach deswegen weil ein herkömmliches Poti
auch keine hat.
Wolfgang A. schrieb:> Normalerweise erwartet man von einem Drehregler, dass er pro Rastung> eine Zustandsänderung macht.
Nein. Zumindest nicht wenn du mit "Zustandsänderung" das gleiche meinst
wie ich: "Übergang von einem Codewert zu einem unmittelbar benachbarten
Codewert". Und zwar will man das genau deswegen nicht, weil dann die
Rastung in der Mitte jedes stabilen Zustandes liegen müßte. So genau
kann man rastende Drehgeber nicht bauen.
Wenn man nur alle 2 Zustandsänderungen (aka 2 Rastpunkte pro Impuls)
oder gar nur alle 4 Zustandsänderungen (aka 1 Rastpunkt pro Impuls)
einen Rastpunkt hat, dann findet man zwischen den Rastpunkten immer
einen nicht-kippelnden Übergang, den man zum Zählen verwenden kann.
Ich frage mich langsam, ob überhaupt irgend jemand mal den Artikel
Drehgeber komplett und aufmerksam gelesen hat. Da steht das alles.
Zur Auswertung ist eigentlich alles gesagt: die macht man im
Timer-Interrupt. "Endlosschleife" ist natürlich Blödsinn, genauso der
Vergleich mit Sleep(0.001). 1000 Abfragen pro Sekunde sind Pillepalle,
die macht ein AVR der mit ein paar MHz läuft, mit Links.
Ich persönlich würde einen Encoder mit möglichst hoher Auflösung (also
bspw. 64 Schritte pro Umdrehung uder mehr) nehmen, damit man nicht
"Kurbeln" muss.
Am angenehmsten empfinde ich Lautstärkerregler ohne Rastungen. Wenn du
trotzdem einen mit Rastungen nimmst (und sei es nur, weil diese billiger
sind), ist die Auflösung durch die Anzahl der Rastungen pro Umdrehung
gegeben. Also sollte deren Zahl möglichst hoch sein.
Sven schrieb:> - einige haben doppelt so viele Rastungen, wie Impulse, andere gleich> viele. Muss ich dann im ersten Fall 2x weiter drehen, um eine Änderung> des Signals zu erhalten?>> - bei den STEC12E ist (lt. Datenblatt) der Rastpunkt auf der Flanke, bei> den STEC11B nicht. Hat das eine Vorteile?
Wieviele Rastungen der Encoder pro Impuls hat und ob die Rastungen auf
oder zwischen den Flanken liegen, ist – jeweils für sich gesehen –
zunächst relativ egal. In Kombination miteinander spielen sie aber
trotzdem eine (wenn auch kleine) Rolle:
Ein Encoder mit mindestens zwei garantierten Flanken zwischen zwei
Rastungen erlaubt es, die Signale so auszuwerten, dass der Zähler
zwischen zwei Rastungen beim Vorwärts- und Rückwärtsdrehen an zwei
verschiedenen Punkten seinen Wert ändert. Durch diese Hysterese erreicht
man, dass auch bei sehr langsamer Drehung der Zähler an den Übergängen
nicht hin- und herflattert, sondern immer monoton aufwärts- bzw. abwärts
zählt. Dieses Flattern ist zwar normalerweise nicht hörbar, aber gut
sichtbar, wenn mit dem Lautstärkeregler eine digitale Anzeige verbunden
ist.
1
Garantierte Anzahl der Flanken zwischen zwei Rastungen
2
3
Rastungen pro Impuls
4
1 2
5
——————————————————————————————————————————————
6
Rastung auf Flanke 3 1
7
Rastung zwischen Flanken 4 2
8
——————————————————————————————————————————————
Bei einem Encoder mit 2 Rastungen pro Impuls und Rastung auf den Flanken
ist diese Hysterese also nicht realisierbar. Deswegen würde ich einen
anderen nehmen, der ja deswegen nicht teurer sein muss.
Eine Dynamik empfinde ich persönlich als grausam, sowohl bei der
Computermaus als auch beim Lautstärkeregler, aber das ist natürlich
Geschmackssache. Für mich muss ein bestimmter Drehwinkel immer derselben
Lautstärkeänderung in dB entsprechen, unabhängig von der aktuell
eingestellten Lautstärke und unabhängig von der Drehgeschwindigkeit.
Meine Finger "wissen" nämlich nach einer kurzen Eingewöhnungsphase
genau, wie sie sich verknuddeln müssen, um mit einmal Hinlangen genau
die gewünschte Lautstärkeänderung zu erhalten. Allerdings bewegen sie
sich – je nach Tagesform – nicht immer gleich schnell :)
Zum Thema zyklischen Polling vs. Interrupts auf Signalflanken:
Das zyklische Polling braucht im Mittel mehr Rechenzeit. Da diese
Rechenzeit aber sowieso vorgehalten werden muss (es sollen beim Drehen
des Encoders ja keine anderen Aktivitäten des Prozessors verlangsamt
werden), ist das m.E. akzeptabel.
Bei den Interrupts auf Signalflanken ist die benötigte Rechenzeit
abhängig von der Impulsfrequenz, die von der Drehgeschwindigkeit
abhängt, aber beim Prellen/Flattern des Encoders auch sehr viel höher
werden kann.
Um zu verhindern, dass durch das Prellen/Flattern des Encoders so viele
Interrupts erzeugt werden, dass der Prozessor nur noch mit der
Interruptbearbeitung beschäftigt ist und damit das gesamte System
zeitweise lahmgelegt wird, müssen die Signale bereits außerhalb des
Prozessors geeignet konditioniert werden, bspw. mit einem RC-Tiefpass
und einem Schmitt-Trigger, was allerdings zusätzlichen Hardware-Aufwand
bedeutet.
Man könnte sich allenfalls noch eine kombinierte Lösung vorstellen: Das
Polling wird bei stillstehendem Encoder abgeschaltet und erst beim
Auslösen eines Pin-Change-Interrupts auf einer der beiden Leitungen
wieder aktiviert. Währende der Polling-Phase werden die externen
Interrupts gesperrt, so dass man auch die Vorfilterung der Signale
verzichten kann. Ob die durch die Deaktivierung eingesparte Rechenzeit
wirklich sinnvoll genutzt werden kann, hängt von der Anwendung ab.
Am allereinfachsten (sowohl hardware- als auch softwareseitig) ist aber
nach wie vor die Auswertung in einem zyklischen Timer-Interrupt. Wenn
sich einige – aus welchen Gründen auch immer – das Leben unötig schwer
machen wollen, ist das ihr gutes Recht. Aber gerade dann, wenn man so
etwas zum ersten Mal macht, muss man sich nicht unbedingt noch selber
Steine in den Weg legen.
Sven schrieb:> Hmm... 1000x pro Sekunde ist schon heftig. Das Programm>> import time> while True:> time.sleep(0.001)>> verursacht bei mir eine dauerhafte CPU-Last von ca. 8%.
Du möchtest die Encoderauswertung doch nicht etwa in Python machen?
Allein der Aufruf-Overhead von time.sleep() braucht mindestens um den
Faktor 10 länger als die komplette Verarbeitung der beiden Encoder-
Signale durch eine C-Funktion. Deswegen sind die von dir ermittelten 8%
alles andere als repräsentativ.
Du solltest allerdings beachten, dass auf einem RasPi (im Gegensatz etwa
zu einem AVR) Interrupthandling generell ein rechenzeitmäßig recht
aufwendiges Unterfangen ist, insbesondere dann, wenn du Linux (oder ein
andere Betriebssystem) laufen hast und die Encoderauswertung dort im
Userspace machen möchtest. Ein Trockentest (aber nicht in Python ;-))
bringt da mehr Klarheit.
Je nachdem, welche weiteren interruptgesteuerten Treiber auf dem RasPi
aktiv sind, kann es dir u.U. sogar passieren, dass hin und wieder
Encoderimpulse verloren gehen. Zum Glück fällt das aber bei einer
Lautstärkeregelung normalerweise keinem auf ;-)
Achso, im Optimalfall nimmt man natuerlich weder Interrupts noch
Polling, sondern einen Controller mit bereits fertigem Eingang. Der
macht dann die gesamte Auswertung in Hardware. Ein AVR kann das aber
nicht.
S. R. schrieb:> Der> macht dann die gesamte Auswertung in Hardware. Ein AVR kann das aber> nicht.
Warum schreibst Du denn so etwas? Ein AVR lacht sich bei der Arbeit
höchstens kaputt, was dann zu einem Ausfall führen könnte.
Oder denkst Du an Dekoder mit 32-Bit parallel Schnittstelle und
DMA-Transfer?
Yalu X. schrieb:> Garantierte Anzahl der Flanken zwischen zwei Rastungen>> Rastungen pro Impuls> 1 2> ——————————————————————————————————————————————> Rastung auf Flanke 3 1> Rastung zwischen Flanken 4 2> ——————————————————————————————————————————————>> Bei einem Encoder mit 2 Rastungen pro Impuls und Rastung auf den Flanken> ist diese Hysterese also nicht realisierbar. Deswegen würde ich einen> anderen nehmen, der ja deswegen nicht teurer sein muss.
Och nöö, nicht schon wieder.
Auch Drehgeber mit Flankenwechsel auf der Rastung lassen sich problemlos
fehlerfrei auswerten, siehe den eigenen Artikel
https://www.mikrocontroller.net/articles/Drehgeber#Dekoder_f.C3.BCr_Drehgeber_mit_wackeligen_Rastpunkten
nur darf man bei ihnen nicht Phase A und Phase B egal wie rum
anschliessen, sondern eben richtig.
Der Übergang von einer Rastung zur anderen geht über den Flankenwechsel
dazwischen.
Theoretisch können Drehgeber Rastungen an verschiedenen Stellungen
haben:
<pre>
--- ---
A | | | |
-- --- ---
--- --- -
B | | | | |
--- ---
1. x x x x x x x x x
2. x x x x x
3. x x x x (der Panasnic von Pollin)
4. x x x
</pre>
Interessant ist hier 3, weil dort die Rastungen auf den Flanken von A
liegen. Aber das macht nichts, wenn an den Übergängen von B gezählt wird
(per polling natürlich, nicht per Flankeninterrupt). Und das ist
ausreichend, denn mehr als 1 Impuls pro Rastung muss man nicht erzeugen
, 4. ist also unsinnig. 1. wäre am effektivsten.
Michael B. schrieb:> Och nöö, nicht schon wieder.
Lies lieber noch einmal meinen Beitrag, bevor du hier herumtröötest :)
Michael B. schrieb:> Auch Drehgeber mit Flankenwechsel auf der Rastung lassen sich problemlos> fehlerfrei auswerten
Ich würde es so ausdrücken: Sie erfüllen voll und ganz ihre Funktion,
aber in manchen Fällen mit einem kleinen Schönheitsfehler.
Yalu X. schrieb:> Durch diese Hysterese erreicht man, dass auch bei sehr langsamer> Drehung der Zähler an den Übergängen nicht hin- und herflattert,> sondern immer monoton aufwärts- bzw. abwärts zählt. Dieses Flattern> ist zwar normalerweise nicht hörbar, aber gut sichtbar, wenn mit dem> Lautstärkeregler eine digitale Anzeige verbunden ist.
Das Flattern geschieht nicht in der Ruhestellung des Encoders (also auf
den Rastpunkten), sondern während des Wechsels von einem Rastpunkt zum
nächsten. Dort stört es in vielen Fällen nicht, in manchen aber doch.
Dann kann man es mit einer Hysterese beseitigen, dazu braucht man aber
mindestens 2 Flanken, die definiert zwischen den beiden Rastpunkten
liegen. In deinem Beispiel (3) liegt nur 1 Flanke dazwischen bei einigen
der Alps-Encoder von Reichelt ebenso. Somit kann der Schönheitsfehler
bei diesen Encodern nicht beseitigt werden.
Ist jetzt etwas klarer, was ich gemeint habe?
Jaja, die lieben Religionskriege. Erst war es der LED-Vorwiderstand,
dann AVR gegen PIC, heute ist es die Drehgeberauswertung. Was kommt
morgen? E-Auto gegen Hoverboard?
Ich würde es so ausdrücken:
"Sie erfüllen voll und ganz ihre Funktion", wenn man sie richtig
verwendet.
Yalu X. schrieb:> In deinem Beispiel (3) liegt nur 1 Flanke dazwischen bei einigen> der Alps-Encoder von Reichelt ebenso. Somit kann der Schönheitsfehler> bei diesen Encodern nicht beseitigt werden.>> Ist jetzt etwas klarer, was ich gemeint habe?
Ja, du sagst nur, daß du es immer noch nicht verstanden hast.
Es spielt keine Rolle, daß A ständig seinen Wert ändert, wenn Drehgeber
3 auf der Rastposition steht, wenn man nur bei Pegelwechseln von B
zählt.
1
--- ---
2
A | | | |
3
-- --- ---
4
--- --- -
5
B | | | | |
6
--- ---
7
3. x x x x (Rastpunkte der Panasonic von Pollin)
8
9
^ ^ ^ ^ ^ Zählpunkte (also +1 bzw. -1)
Bei Pegelwechseln von A wird die Lautstärke oder der sonst was
beeinflussende Wert nicht verändert. Daher sprach man vorher von
"geteilt durch 2".
Michael B. schrieb:> Bei Pegelwechseln von A wird der die Lautstärke oder sonst was> beeinflussende Wert nicht verändert.
Genau. Aber an den Pegelwechseln von B. Richtig?
Mach mal folgendes Experiment:
Der Zählerstand sei zu Beginn 0. Jetzt drehst du den Encoder gaaanz
langsam vom aktuellen Rastpunkt zum nächsten. Irgendwo auf halbem Weg
springt der Zähler auf 1. Da deine Hand aber etwas zittert¹, springt er
kurzzeitig wieder auf 0 zurück und dann sofort wieder auf 1. So geht das
ein paarmal hin und her, bis du den Bereich des Zählpunkts verlassen
hast. Wenn der Encoder beim nächsten Rastpunkt einrastet, bleibt der
Zählerstand natürlich stabil auf 1.
Die Folge der Zählerstände über der Zeit sieht also etwa so aus (die 'v'
sind dabei die Rastpunkte):
Variante 1:
1
v v v
2
000000010110111111111111111112212122222222222222
3
——————————————————————————————————————————————————> t
Bei einer Auswertung mit Hysterese sähe das Ergebnis hingegen so aus:
Variante 2:
1
v v v
2
000000000000001111111111111111111122222222222222
3
——————————————————————————————————————————————————> t
Erkennst du den Unterschied?
Eine angeschlosse digitale Anzeige würde in Variante 1 im Bereich des
Zählpunkts zappeln, in Variante 2 nicht.
Erst wenn die Zitterbewegungen der Hand größer sind als die Hysterese
(also etwa ein Drittel des Rastpunktabstands), zappelt auch Variante 2.
Aber ganz so alt sind wir vermutlich noch nicht ;-)
Du kannst dich mit Variante 1 abfinden. Ich kann das zur Not auch.
Wenn ich aber den Encoder sowieso erst bestellen muss und die freie Wahl
habe, nehme ich doch lieber einen, der Variante 2 erlaubt, oder?
———————————
¹) wenn nicht deine Hande, dann tut's der Encoder
Hallo,
hier noch der optische Drehgeber, den ich einsetze:
https://hbe-shop.de/Art-1607977-BOURNS-ENA1J-B28-L00064L-SENSORENCODEROPTIK
ist von HBE, kostet 31.10 Euro. Natürlich ist das teurer als ein
Drehgeber mit Schaltkontakten, dafür ist er verschleißfrei, ruckelfrei
und leichtgängig. Er hat keine Rastung, es gibt auch wenig Probleme, daß
er genau auf einer Flanke stehen bleibt, etwas Hysterese hat er
offensichtlich eingebaut.
Bedenken muß man, daß er mit 5V versorgt wird und die Ausgänge auch bis
auf 5V treibt, beim Anschluß an einen Raspberry Pi oder Arduino Due muß
man Transistoren und Pullups nach 3V3 dazwischen schalten. Daß die
Ausgänge dann invertiert sind, macht nichts, man muß nur die Logik
passend machen oder die Ausgänge vertauschen.
Auch bedenken, daß die Achse einen Durchmesser von 6.35mm hat, passende
Knöpfe sind selten, gibt es aber z.B. bei Conrad: Best-Nr. 429924
(Knopf) und 425534 (Kappe) mit 15mm Außendurchmesser oder 429912 (Knopf)
und 425546 (Kappe) mit 20mm Außendurchmesser.
Da mein Vorverstärkerprojekt wohl ca. 2000Euro kosten wird (zu kaufen
gibt es das nicht, was ich haben will), sind die Kosten für die
Drehgeber gerechtfertigt. Für Kleingeräte eher zu teuer.
Gruß
Andy
Yalu X. schrieb:> Irgendwo auf halbem Weg springt der Zähler auf 1.
Warum?
Bei mir springt der Zähler, wenn er den nächsten Rastpunkt erreicht hat.
Yalu X. schrieb:> Eine angeschlosse digitale Anzeige würde in Variante 1 im Bereich des> Zählpunkts zappeln, in Variante 2 nicht.>> Erst wenn die Zitterbewegungen der Hand größer sind als die Hysterese> (also etwa ein Drittel des Rastpunktabstands), zappelt auch Variante 2.> Aber ganz so alt sind wir vermutlich noch nicht ;-)>> Du kannst dich mit Variante 1 abfinden. Ich kann das zur Not auch.> Wenn ich aber den Encoder sowieso erst bestellen muss und die freie Wahl> habe, nehme ich doch lieber einen, der Variante 2 erlaubt, oder?
Das ist doch alles Bullshit. Der kann zwischen Rastpunkt und
Flankenwechsel pendeln wie er will. Da kriegt auch kein Vollalkoholiker,
bevor er morgens bei Edeka war, den Zähler zum Wackeln.
mfg.
Yalu X. schrieb:> Erkennst du den Unterschied?
Der eine mit Prellen, der andere ohne,
aber keiner von beiden prellt an den Rastpunkten wie es der von Pollin
tut.
Yalu X. schrieb:> Eine angeschlosse digitale Anzeige würde in Variante 1 im Bereich des> Zählpunkts zappeln,
Wenn diese Anzeige die 4 unterscheidbaren Zustände des
Inkrementalencoders schnell genug erkennt, sicherlich. Ob prellen oder
ein vibrieren der Welle oder eine elektromagnetische Einstreuung im
Umschaltpunkt ist ja aus Sicht der Elektronik ununterscheidbar.
> Erst wenn die Zitterbewegungen der Hand größer sind als die Hysterese
Hysterese funktioniert nur, wenn der Incrementalencoder mehr Positionen
liefert, als du wirklich brauchst, in deinem Beispiel doppelt so viele
die dann durch 2 geteilt deine gezählte Ausgabe ergeben.
Dein erstes (gestörtes und für dich nicht behandelbares) Signal nutzt
aber jede Position
1
- -----------------------------------
2
A ||| ||
3
------
4
----------------------------
5
B | |||
6
- --------------
7
8
v v v
9
000000010110111111111111111112212122222222222222
10
——————————————————————————————————————————————————> t
dein zweites, das erst bei einer Zählerstandsabweichung von +2
um 1 höher zählt, braucht doppelt so viele Positionen
1
- -----------------
2
A | || | ||
3
--- - -------------------
4
------------- - - ---------
5
B || | | ||
6
----------------
7
v v v
8
000011011111112112222222233233333344344444444444 <- eigentliche Position
Max M. schrieb:> Meine Meinung: Interrupt!> ...> 2. Der MC hat normalerweise was besseres zu tun als sinlos Eingänge zu> pollen.
z.B. darauf zu warten, dass ein Interrupt kommt.
Thomas E. schrieb:> Yalu X. schrieb:>> Irgendwo auf halbem Weg springt der Zähler auf 1.>> Warum?> Bei mir springt der Zähler, wenn er den nächsten Rastpunkt erreicht hat.
Nein, der Zähler soll ja auf dem Rastpunkt stabil sein und dort nicht
springen. Springen soll er zwischen den Rastpunkten, das ist schon in
Ordnung. Die Frage, auf die ich hinaus möchte ist, wie der Zähler an
zwischen zwei Rastpunkten springt, ob entprellt oder nicht. Und eine
Entprellung ist an dieser Stelle eben nur dann möglich, wenn es zwischen
zwei Rastpunkten zwei Flanken (eine von A und eine von B) gibt anstatt
nur eine (bspw. nur von B).
Michael B. schrieb:> Yalu X. schrieb:>> Eine angeschlosse digitale Anzeige würde in Variante 1 im Bereich des>> Zählpunkts zappeln,>> Wenn diese Anzeige die 4 unterscheidbaren Zustände des> Inkrementalencoders schnell genug erkennt, sicherlich.
Auch dann, wenn die Anzeige nur den für den Endandwender interessante
halbierten Wert anzeigt. Dann zappelt die Anzeige zwar nicht mehr an den
Rastpunkten, aber immer noch an den Übergangspunkten dazwischen.
Hmm, irgendwie habe ich es offensichtlich überhaupt nicht geschafft,
diesen an sich nicht sehr komplexen Zusammenhang verständlich
darzustellen, habe jetzt aber leider keine Zeit, das noch einmal auf
andere Weise zu formulieren.
Evtl. werde ich am Wochenende einen weiteren Versuch starten :)
Yalu X. schrieb:> Nein, der Zähler soll ja auf dem Rastpunkt stabil sein und dort nicht> springen
Entweder verstehst du es nicht oder du willst es nicht verstehen.
Der Zähler ist stabil. Er inkrementiert oder dekrementiert genau
einmal, je nach Drehrichtung. Der nächste Zählvorgang findet auf dem
nächsten Rastpunkt statt. Was dazwischen wackelt, prellt oder pendelt,
ist vollkommen egal.
Yalu X. schrieb:> Hmm, irgendwie habe ich es offensichtlich überhaupt nicht geschafft,> diesen an sich nicht sehr komplexen Zusammenhang verständlich> darzustellen, habe jetzt aber leider keine Zeit, das noch einmal auf> andere Weise zu formulieren.
Vielleicht solltest du einmal über deinen Tellerrand hinweg schauen und
einfach die Möglichkeit in Betracht ziehen, dass es Auswertungen gibt,
die die von dir geschilderten Probleme einfach nicht haben.
mfg.
Yalu X. schrieb:> Hmm, irgendwie habe ich es offensichtlich überhaupt nicht geschafft...
Na, ich versuch's mal:
Also, die Drehgeber, über die wir hier reden, haben Rastungen und
mechanische Schleifkontakte.
Grundsätzlich sind alle Drehgeber so konstruiert, daß sie 2 Signale
liefern: eines (nennen wir das hier mal A), das anzeigt ob überhaupt
eine Drehbewegung stattfand und ein anderes, das anzeigt, in welche
Richtung die Bewegung ging (was wir hier mal D nennen wollen).
Deshalb ändern sich immer beide Signale im Drehverlauf von einer
Rastung zur anderen.
Bei vielen Drehgebern ändert sich das D Signal direkt in den Rastungen
oder in deren Nähe, wohingegen das A Signal möglichst in der Mitte
zwischen zwei Rastungen sich ändert. Der 95Ct-Pollin-DG von Panasonic
ist so einer.
Es gibt aber auch Drehgeber, wo A und D und Rastungen durch gleiche
Winkelabstände voneinander getrennt sind, so daß niemals zwei Dinge
(A,D,Rastung) zusammenfallen.
Ich hab hier auch ein Beispiel von ALPS, wo (aus Sicht der Signale A und
D jede zweite Rastung entfallen ist.
Jaja, es gibt auch noch exotischere Signalverläufe, wo z.B. von Rastung
zu Rastung jeweils 2 Pegeländerungen bei beiden Signalen zu beobachten
sind, aber die sind glücklicherweise Exoten.
Zur Auswertung:
Grundsätzlich muß man zu dem Zeitpunkt, wo sich das A Signal ändert, den
Pegel des D Signals erfassen, da man nur so die Richtung feststellen
kann. Zu einem späteren Zeitpunkt ist das fast immer unmöglich, da man
dann ja in den Bereich gekommen ist, wo sich das D Signal ändert.
Also muß man die Änderung von A irgendwie bemerken.
Manche schwören auf Polling, weil Schleifkontakte ja prellen. Aber das
muß erstens sau-oft stattfinden, damit man zeitnah D erfassen kann und
zweitens steht man dann auch noch vor der Aufgabe, das Prellen
softwaremäßig abzufangen.
Andere (mich eingeschlossen) sehen das anders, machen eine Entprellung
per Hardware durch zwei nette Kondensatoren an A und D gegen Masse und
benutzen einen Interrupt für das Erkennen der Änderung von A. Es gibt
auch µC, die eine Entprellung in ihrer Portlogik eingebaut haben, das
wird dann noch schicker. Aber zwei poplige C's tun's auch.
(warum auch bei D nen Kondensator? Weil beim Schleifen des geschlossenen
Kontaktes sonst dort auch Spikes auftreten könnten)
Auf welche Flanken von A man testen (beim Polling) oder interrupten muß,
hängt vom konkreten Drehgeber ab. Bei den meisten muß man auf beide
Flanken reagieren und dann das Exclusiv-OR aus beiden Signalen bilden,
um die Drehrichtung zu erkennen.
billiges Beispiel für den Pollin-DG:
bei Interrupt:
begin
Richtung:= A xor D;
if Richtung=true
then istVorwärts
else istRückwärts;
end;
Das ist eigentlich alles, was es dazu zu sagen gibt.
W.S.
Yalu X. schrieb:> Evtl. werde ich am Wochenende einen weiteren Versuch starten :)
Spar Dir die Mühe. Das Thema ist Religion und das Geschreie dazu
vorprogrammiert. Unstabile Übergangszustände bei mechanischen Kontakten
sind m.E. auch völlig überbewertet. Wie war das noch mal mit dem Typen,
der nur einen Hammer hat und daher nur noch Nägel sieht?
Letztlich ist der TO nur verunsichert und seine Frage bleibt
unbeantwortet.
Andreas W. schrieb:> hier noch der optische Drehgeber, den ich einsetze:> https://hbe-shop.de/Art-1607977-BOURNS-ENA1J-B28-L00064L-SENSORENCODEROPTIK> ist von HBE, kostet 31.10 Euro.
Das ist die Edelversion, die es auch mit anderen Auflösungen gibt.
Robust und günstig ist ein Schrittmotor aus der Ramschkiste.
Nachtrag: bei nem optischen DG, wo die Entprellung bereits enthalten
ist, braucht man sich natürlich um selbige gar nicht mehr zu kümmern.
Aber: Yalu's Einwurf wegen der zittrigen Hand ist bei optischen DG mit
64..256 Positionen/Umdrehung durchaus bereichtigt. Das hat aber nix mit
der korrekten DG-Erkennung zu tun.
W.S.
W.S. schrieb:> Aber: Yalu's Einwurf wegen der zittrigen Hand ist bei optischen DG mit> 64..256 Positionen/Umdrehung durchaus bereichtigt.
Daher ja auch mein Vorschlag, mit Dynamik zu arbeiten, auch wenn Yalu
das nicht mag ;-)
W.S. schrieb:> Grundsätzlich sind alle Drehgeber so konstruiert, daß sie 2 Signale> liefern: eines (nennen wir das hier mal A), das anzeigt ob überhaupt> eine Drehbewegung stattfand und ein anderes, das anzeigt, in welche> Richtung die Bewegung ging (was wir hier mal D nennen wollen).
Au weia. Klarer Fall von nicht verstanden.
Beide Signale sind absolut austauschbar. Eine Auswertung, die nicht
beide Signale absolut identisch behandelt, geht an der Physik vorbei,
und jeder sollte sich fragen, warum sie unterschiedlich behandelt
werden.
W.S. schrieb:> Es gibt aber auch Drehgeber, wo A und D und Rastungen durch gleiche> Winkelabstände voneinander getrennt sind, so daß niemals zwei Dinge> (A,D,Rastung) zusammenfallen.
Ja. Da mechanische Ungenauigkeiten existieren, muss man davon ausgehen,
daß Rastungen durchaus dort sein können wo ein Signalwechsel auftritt,
ausserdem gibt es ja noch Millionen von Drehgebern ohne Rastungen, bei
deiner Maus oder an einer Motorwelle zu Positionierzwecken wie in
Tintenstrahldruckern. Ob und wo Rastungen sind, muss einer Auswertung
also egal sein können.
W.S. schrieb:> Zur Auswertung:> Grundsätzlich muß man zu dem Zeitpunkt, wo sich das A Signal ändert, den> Pegel des D Signals erfassen, da man nur so die Richtung feststellen> kann. Zu einem späteren Zeitpunkt ist das fast immer unmöglich, da man> dann ja in den Bereich gekommen ist, wo sich das D Signal ändert.
Grundsätzlich ist das falsch.
http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29W.S. schrieb:> Das ist eigentlich alles, was es dazu zu sagen gibt.
Nicht wirklich, und vor allem am Thema vorbei.
Yalu möchte darauf hin, daß mit einer Auswertung die er Hysterese nennt
und die aus der wahren Drehgeberposition x eine halb so hoch auflösende
Position y macht,
1
if(x&1) y=x/2; // egal ob Vorwärts- oder Rückwärtsrichtung
durch einfache (also nur ein Kanal ändert sich hin und her)
Signalwechsel kein +1 und -1 der Auswerteposition mehr erfolgt. Das ist
richtig, aber es funktioniert auch, wenn der Signalwechsel an der
Rastposition liegt, wie beim Pollin Encoder.
Irgendwie scheint mir die ganze Diskussion ziemlich müßig. Es geht
darum, ein (Taster), zwei (Drehgeber) oder auch viele asynchrone Signale
in eine synchrone (Prozessor) Umgebung zu bringen. Dazu verwenden die
Designer digitaler Logic Flipflops, die synchron mit dem Takt der
Zieldomain laufen (Timerinterrupt).
Irgendwelcher analoger Pfusch wie Kondensatoren, der aus sauberen
digitalen Signalen erstmal Sägezähne macht, den man dann wieder
digitalisieren muß, gehört da nicht hin. Ich hab jedenfalls in einem
FPGA noch keinen Kondensator im Signalpfad gefunden und erwarte dort
ebenfalls keine flankengetriggerten Flipflops (Interrupte) sondern ein
rein synchrones Design.
MfG Klaus
Klaus schrieb:> Irgendwie scheint mir die ganze Diskussion ziemlich müßig.
Das mag sein, aber warum diskutierst Du dann trotzdem mit?
Klaus schrieb:> Irgendwelcher analoger Pfusch wie Kondensatoren, der aus sauberen> digitalen Signalen erstmal Sägezähne macht, den man dann wieder> digitalisieren muß, gehört da nicht hin.
Der Ausdruck "Filter" sagt Dir wahrscheinlich nicht viel. Sicher ist:
Wenn man einen analogen Tiefpaß, der mit SMD-Bauelementen schon auf den
Leiterzügen "verschwindet" nutzen kann, braucht man keinen digitalen im
Kontroller zu programmieren und kann sich dort sowohl Speicherplatz als
auch Fehlerquellen ersparen.
Andreas Kreuz schrieb:> der mit SMD-Bauelementen schon auf den> Leiterzügen "verschwindet" nutzen kann
Das hat mit Größe nichts zu tun. Das Bearbeiten von digitalen Signalen
mit analogen Mitteln ist einfach Pfusch und schon die Fehlerquelle an
sich. Es zeigt nur, daß der entsprechende Entwickler den Übergang von
asynchronen Designparadigmen zu den heute gängigen synchronen verpennt
oder nicht verstanden hat.
MfG Klaus
Klaus schrieb:> Das hat mit Größe nichts zu tun. Das Bearbeiten von digitalen Signalen> mit analogen Mitteln ist einfach Pfusch und schon die Fehlerquelle an> sich. Es zeigt nur, daß der entsprechende Entwickler den Übergang von> asynchronen Designparadigmen zu den heute gängigen synchronen verpennt> oder nicht verstanden hat.
Nana, in diesem Falle bist du derjenige, der da was verpennt hat.
Vielleicht solltest du dir mal vor Augen führen, daß die reale Welt
durchgehend analog ist. Auch das Signal aus einem Drehgeber - ob nun
optisch oder per Schleifkontakt - ist rein analog. Und das mit allen
Dingen, die aus digitaler Sicht nur unerwünschte Störgrößen sind.
W.S.
m.n. schrieb:> Daher ja auch mein Vorschlag, mit Dynamik zu arbeiten, auch wenn Yalu> das nicht mag ;-)
Naja, ist ein eher schwieriges Thema. Man muß ne Menge am konkreten
Objekt experimentieren, bis das Ganze wirklich gut in der Hand liegt.
Mein AR7030 kann das prächtig, aber ich halte mich da lieber zurück. Es
müßte notwendig sein oder zumindest nen deutlichen Gebrauchs-Mehrwert
liefern, um sich da hinein zu stürzen. Da kann ich Yalu irgendwie
verstehen.
Aber dieser Thread ist ohnehin versaut.
W.S.
W.S. schrieb:> Vielleicht solltest du dir mal vor Augen führen, daß die reale Welt> durchgehend analog ist.
Wohl wahr, trotzdem scheint sich der Analogrechner nicht so recht
durchgesetzt zu haben, sind analoge Schaltungen so langsam am
Verschwinden, macht man alles so früh im Signalpfad digital, wie nur
möglich.
Die Zeit asynchroner Logikdesigns ist auf jeden Fall vorüber und wie man
Signale einsynchronisiert ist hinreichend bekannt: Abtasten mit
hinreichend hoher Frequenz, also in diesem Fall für die Drehfrequenz
ausreichend schneller Timerinterrupt. Die Prozessoren mit eingebautem
Drehgeber Interface machen in einer Hardware-Statemaschine genau das
Gleiche.
MfG Klaus
Thomas E. schrieb:> Bei mir springt der Zähler, wenn er den nächsten Rastpunkt erreicht hat.
Dann hast du die beiden Geberkanäle vertauscht. Der Zähler soll
zwischen den Rastpunkten springen.
Wolfgang schrieb:> Dann hast du die beiden Geberkanäle vertauscht. Der Zähler soll> zwischen den Rastpunkten springen.
Woher willst du wissen, wann mein Zähler zählen soll?
Wenn ich die Geberkanäle tausche, zählt er andersrum.
mfg.
@Michael Bertrandt und Thomas Eckmann:
Zur Diskussion
- Lage der Rastpunkte relativ zu den Signalflanken
- Vor- und Nachteile, gibt es überhaupt welche?
die ich mit meinem Beitrag von oben losgetreten habe:
Yalu X. schrieb:> Ein Encoder mit mindestens zwei garantierten Flanken zwischen zwei> Rastungen erlaubt es, die Signale so auszuwerten,
Ich habe eure Beiträge noch einmal durchgelesen und den Eindruck
gewonnen, dass wir – zumindest teilweise – aneinander vorbeireden.
Aus diesem Grund habe ich mein oben Geschriebenes in zwei Skizzen
zusammengefasst, die – wie ich meine – den Unterschied zwischen den
beiden diskutierten Drehgebertypen bie jeweils optimaler Auswertung
deutlich machen.
Vielleicht habe ich aber seit Tagen ein gewaltiges Brett vor dem Kopf
und, das, was ich da skizziert habe, ist Unfug. Dann sagt mir bitte,
welcher Teil der Skizzen nicht stimmt.
Michael B. schrieb:> Hysterese funktioniert nur, wenn der Incrementalencoder mehr Positionen> liefert, als du wirklich brauchst, in deinem Beispiel doppelt so viele> die dann durch 2 geteilt deine gezählte Ausgabe ergeben.
Beide Drehgebertypen haben 2 Rastpunkte pro Impuls. Der Unterschied
zwischen den beiden liegt einzig und allein in der Lage der Rastpunkte
relativ zu den Signalflanken. Aber gerade dieser Unterschied erlaubt es
meiner Meinung nach bei Typ 2, das Zählerflattern mittels Hysterese zu
eliminieren, wohingegen dies bei Typ 1 nicht möglich ist.
Thomas E. schrieb:> Vielleicht solltest du einmal über deinen Tellerrand hinweg schauen und> einfach die Möglichkeit in Betracht ziehen, dass es Auswertungen gibt,> die die von dir geschilderten Probleme einfach nicht haben.
Ich interpretiere deine Aussage so, dass mit einer geeigneten Auswertung
auch bei Typ 1 das Zählerflattern eliminiert werden kann. Kannst du mir
vielleicht in kurzen Worten erklären, wie?
An beide von euch:
Ich meine, aus euren Beiträgen herauslesen zu können, dass eurer Meinung
nach beide Drehgebertypen völlig gleichwertig sind, wenn man nur das
jeweils richtige Auswerteverfahren anwendet. Ich frage mich dann
allerdings, warum ein und derselbe Hersteller (nämlich Alps) beide Typen
im Programm hat?
Yalu X. schrieb:> Ich frage mich dann allerdings, warum ein und derselbe> Hersteller (nämlich Alps) beide Typen im Programm hat?
Du hast 2 Diagramme in deinem Artikel.
Du behauptest, beide wären unterschiedlich.
Der wesentliche Unterschied ist aber deine Auswertung,
bei einen hast du das eingebaut was du Hysterese nennst,
beim anderen nicht.
Man kann beide Drehgeber auf beide Arten auswerten.
Nimm doch Drehgeber 1 und werte ihn mit Hysterese aus.
Oder nimm Drehgeber 2 und werte ihn ohne Hysterese aus.
Es liegt nicht am Drehgeber, es liegt an der Auswertung.
So lange man die Auflösung des Drehgebers durch 2 teilen kann,
erlauben beide dieselbe Auswertung, wenn man aber jeden Phasenwechsel
zählen will, braucht man Drehgeber Typ 2.
Thomas E. schrieb:> Woher willst du wissen, wann mein Zähler zählen soll?> Wenn ich die Geberkanäle tausche, zählt er andersrum.
Normalerweise wird man wohl immer anstreben, dass man auf der Rastung
einen stabilen Wert hat.
Wenn die Flanke des einen Kanals auf den Rastungen liegen, wird man also
den Auswertealgorithmus so schreiben, dass die Flanken des anderen den
Zählerstand ändern. Sonst hängt die Stabilität des Zählerstandes vom
Spiel der Rastung oder irgendwelchen Schaltschwellendriftereien ab.
Michael B. schrieb:> Man kann beide Drehgeber auf beide Arten auswerten.
Nein, das geht nur bei Typ 2.
> Oder nimm Drehgeber 2 und werte ihn ohne Hysterese aus.
Klar, das geht so, wie du im geänderten Bild gezeigt hast.
> Nimm doch Drehgeber 1 und werte ihn mit Hysterese aus.
Das geht nicht. Stell dir vor, im Bild "typ1.gif" lägen die Rastpunkte
ein kleines Stückchen rechts von den Flanken von B, was ja auf Grund von
Fertigungstoleranzen oder einem leicht ausgeleierten Rastmechanismus
durchaus sein kann. Dann würde der Zähler beim Herunterzählen (im
Diagramm die Bewegungsrichtung von rechts nach links) immer um einen
Schritt hinterherhinken.
Das Problem bei den auf den Signalflanken von Kanal B liegenden
Rastpunkten liegt darin, dass man nie genau sagen kann, ob der Drehgeber
links oder rechts von einer dieser Flanken einrastet. Deswegen können
die Pegeländerungen von Kanal B zwar für interne Zustandsübergänge der
Auswertesoftware verwendet werden (das müssen sie sogar), sie dürfen
aber keinesfalls den nach außen sichtbaren Zählerstand beeinflussen.
Dieser darf seinen Wert ausschließlich an den Pegeländerungen an Kanal A
ändern.
Anders bei Typ 2: Dort liegen nicht nur die Signalflanken von Kanal A,
sondern auch diejenigen von Kanal B ganz klar definiert zwischen den
Rastpunkten.
Deswegen können hier die Flanken von beiden Kanälen als mögliche
Positionen für Zählerstandsänderungen in Betracht gezogen werden.
Dadurch ist es möglich, das Inkrementieren und Dekrementieren des
Zählers an zeitlich und räumlich verschiedenen Positionen stattfinden zu
lassen, was zur gewünschten Hysterese führt.
Die drei Abstände
Rastpunkt <-> Flanke A <-> Flanke B <-> nächster Rastpunkt
sind sinnvollerweise etwa gleich groß gewählt (also jeweils 1/3 des
Rastpunktabstands), so dass die Anordnung maximal robust gegenüber
Fertigungstoleranzen und Verschleiß ist.
Yalu X. schrieb:> Das geht nicht.
Das geht schon.
Das "Flattern" wird durch die Hysterese unterdrückt, und ob der
Drehgeber beim Rastpunkt auf 4 oder 5 gezählt hat ist egal, Drehgeber
sind eh relativ und nicht absolut.
Michael B. schrieb:> Das "Flattern" wird durch die Hysterese unterdrückt
Trotzdem ist man nicht vor einem sporadischen Zählerstandsänderungen auf
dem Rastpunkt sicher, wenn man den Drehgeber kurz vor dem
Hysteresesprung "abgestellt" hat und er z.B. durch Erschütterung oder
Temperaturänderung rüberdriftet und die Flanke kommt.
Michael B. schrieb:> typ1.gif
Yalu X. schrieb:> @Michael Bertrandt und Thomas Eckmann:>> Zur Diskussion>> - Lage der Rastpunkte relativ zu den Signalflanken> - Vor- und Nachteile, gibt es überhaupt welche?>> die ich mit meinem Beitrag von oben losgetreten habe:>> Yalu X. schrieb:>> Ein Encoder mit mindestens zwei garantierten Flanken zwischen zwei>> Rastungen erlaubt es, die Signale so auszuwerten,>> Ich habe eure Beiträge noch einmal durchgelesen und den Eindruck> gewonnen, dass wir – zumindest teilweise – aneinander vorbeireden.>> Aus diesem Grund habe ich mein oben Geschriebenes in zwei Skizzen> zusammengefasst, die – wie ich meine – den Unterschied zwischen den> beiden diskutierten Drehgebertypen bie jeweils optimaler Auswertung> deutlich machen.
Die Auswertung ist doch recht simpel. Wenn das generell über eine
Statemachine im Timerinterrupt macht, wie hier
http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
beschrieben, und sich mal die Zählerwerte, die zum ersten Bild passen
ansieht, bekommt man folgende Werte:
an der ersten Flanke wackelt der Zähler zwischen 0bxxx00 und 0bxxx01. Da
man den Zählerwert sowieso durch 2 teilen muß, ist das "wackelnde" Bit
unerheblich, wird nach rechts herausgeschoben.
Bei der zweiten Flanke (unterer Kanal) wackelt der Zähler von 0bxxx01
nach 0bxxx10. Wenn einen diese Position interessiert (weil da jeweils
die Rastung liegt), muß man den Zähler inkrementieren, bevor man ihn
durch zwei teilt. Alternativ könnte man den Zähler auch mit 1 statt mit
0 initialisieren.
Also alles kein wirkliches Problem
MfG Klaus
Yalu X. schrieb:> Ich interpretiere deine Aussage so, dass mit einer geeigneten Auswertung> auch bei Typ 1 das Zählerflattern eliminiert werden kann. Kannst du mir> vielleicht in kurzen Worten erklären, wie?
Ja:
Thomas E. schrieb:> Yalu X. schrieb:>> Ich interpretiere deine Aussage so, dass mit einer geeigneten Auswertung>> auch bei Typ 1 das Zählerflattern eliminiert werden kann. Kannst du mir>> vielleicht in kurzen Worten erklären, wie?>> Ja:>>
thanksalot schrieb:>> [ironie on] hier steht dann im vorbildlich kommentierten Code alles was man> braucht [ironie off]>>
full ack.
Aber damit kann man Kritik vermeiden und an anderer Stelle wieder dicke
Backe zeigen. Peinlich!
m.n. schrieb:> Aber damit kann man Kritik vermeiden und an anderer Stelle wieder dicke> Backe zeigen. Peinlich!
ein Programm macht immerhin genau das was da als Programmtext steht,
aus dem dem ganzen schwammigen Prosa-Geschwafel in diesem Thread
interpretiert doch jeder was anderes
Walter S. schrieb:> ein Programm macht immerhin genau das was da als Programmtext steht,
Da es hier schon garnicht mehr um die eigentliche Frage geht, sondern um
das WIE&WARUM einer möglichen Auswertung, sind zwangsläufig ein paar
Erklärungen zur Funktion notwendig.
Die PeDa-Manier, eine Funktion unkommentiert in eine Zeile zu pressen,
ist dabei nicht hilfreich.
Thomas E. schrieb:> Yalu X. schrieb:>> Ich interpretiere deine Aussage so, dass mit einer geeigneten Auswertung>> auch bei Typ 1 das Zählerflattern eliminiert werden kann. Kannst du mir>> vielleicht in kurzen Worten erklären, wie?>> Ja:>> #define ENCPIN0 (PINB & (1 << 0))> #define ENCPIN1 (PINB & (1 << 1))
Dein Code passt perfekt zum Drehgebertyp 2 (Rastpunkte liegen zwischen
den Signalflanken). Er funktioniert aber nicht zuverlässig bei Typ 1
(Rastpunkte liegen auf den Signalflanken eines der Kanäle).
Die Gründe dafür wurden in den folgenden Beiträgen bereits genannt:
Yalu X. schrieb:> Das geht nicht. Stell dir vor, im Bild "typ1.gif" lägen die Rastpunkte> ein kleines Stückchen rechts von den Flanken von B, ...Wolfgang schrieb:> Trotzdem ist man nicht vor einem sporadischen Zählerstandsänderungen auf> dem Rastpunkt sicher, ...
Yalu X. schrieb:> Er funktioniert aber nicht zuverlässig bei Typ 1> (Rastpunkte liegen auf den Signalflanken eines der Kanäle).
Nein, das stimmt nicht. Er funktioniert damit gar nicht. Aber der ist
auch ein bisschen abgespeckt.
So klappt das auch mit dem Nachbarn:
Thomas E. schrieb:> So klappt das auch mit dem Nachbarn:>> unsigned char odd[] = {0x01, 0x03, 0x00, 0x02};>> if(ENCPIN0) pins = 1;> if(ENCPIN1) pins += 2;> pins = odd[pins];> ...>> mfg.
Damit verschiebst du de facto die Signale um eine Impulsbreite. Das
Problem bleibt aber: Wo es vorher beim Aufwärtszählen auftrat, tritt es
jetzt beim Abwärstzählen auf.
Mal dir einfach mal ein Diagramm auf, ähnlich wie ich es hier gemacht
habe:
Yalu X. schrieb:> Aus diesem Grund habe ich mein oben Geschriebenes in zwei Skizzen> zusammengefasst
Dann wirst du sehr schnell sehen, wo der Hase im Pfeffer liegt.
Edit:
Es muss im ersten Absatz "um eine halbe Impulsbreite" heißen.
Yalu X. schrieb:> Damit verschiebst du de facto die Signale um eine Impulsbreite. Das> Problem bleibt aber: Wo es vorher beim Aufwärtszählen auftrat, tritt es> jetzt beim Abwärstzählen auf.
Natürlich tritt das Problem in beiden Richtungen nicht auf.
Yalu X. schrieb:> Mal dir einfach mal ein Diagramm auf, ähnlich wie ich es hier gemacht> habe:
Nein.
Nimm du dir einen Controller und einen Drehgeber und probier es aus.
Yalu X. schrieb:> Dann wirst du sehr schnell sehen, wo der Hase im Pfeffer liegt.
mfg.
Thomas E. schrieb:> Yalu X. schrieb:>> Damit verschiebst du de facto die Signale um eine Impulsbreite. Das>> Problem bleibt aber: Wo es vorher beim Aufwärtszählen auftrat, tritt es>> jetzt beim Abwärstzählen auf.>> Natürlich tritt das Problem in beiden Richtungen nicht auf.
D.h. du hast das ein paarmal ausprobiert, dir ist nichts Ungewöhnliches
aufgefallen, und damit ist die Sache für dich abgehakt. Testen ist gut,
ersetzt aber leider nicht das Nachdenken. Was meinst du, warum hier so
oft Fragen der Form
"Ich habe hier eine Schaltung/Software, die funktioniert perfekt.
Jetzt habe die Schaltung genau gleich ein zweites Mal aufgebaut, und
nicht funktioniert mehr. Wie kann das sein?"
gestellt werden?
Ich habe hier einen Panasonic ECEQ, das ist der Encoder, den Pollin für
0,75€ verkauft. Bild eceq-datasheet.png (Auszug aus dem Datenblatt)
zeigt, dass die Rastpunkte nominell auf den Signalflanken von Kanal B
liegen. Bild eceq-real zeigt die realen Verhältnisse für das vorliegende
Exemplar. Wie man leicht erkennen kann, liegen die Rastpunkte nicht
exakt auf den Flanken von B, sondern etwas rechts daneben. Damit ist
dieses Exemplar streng genommen vom Typ 2, bei dem immer jeweils zwei
Signalflanken (eine von A und eine von B) zwischen den Rastpunkten
liegen. Deswegen funktioniert hier auch deine Software, und zwar die
erste Version ohne die nachgereichte Modifikation.
Aber genauso, wie die Offsetspannung eines Opamps je nach Exemplar
einmal positiv und ein andermal negativ sein kann, würde ich hier nicht
darauf vertrauen, dass die Rastpunkte für jedes Exemplar rechts von
den B-Flanken liegen. Offensichtlich hast du, als du deine Software noch
einmal getestet hast, ein Exemplar erwischt, wo die Rastpunkte nicht wie
bei mir rechts, sondern links von den B-Flanken liegen, und schon hat
deine Software nicht mehr funktioniert. Also hast du eine Modifikation
nachgereicht, in der die Signale so konvertiert werden, dass sie efektiv
um eine halbe Impulsbreite bzw. einen halben Rastpunktabstand nach links
verschoben werden. Das hat den gleichen Effekt als würde man die
Rastpunkte nach rechts schieben. Damit sind wieder die ursprünglichen
Verhältnisse hergestellt, und – Juhu! – die Software funktioniert
wieder.
Zumindest so lange, bis du das nächste Encode-Exemplar anschließt.
Eine üble Work-Around-Lösung wäre, nach dem Aufbau der Schaltung jeweils
zu prüfen, ob der Encoder von der rechts- oder der linkslastigen Sorte
ist und den Controller passend dazu entweder mit der unmodifizierten
oder der modifizierten Firmwareversion zu programmieren. Aber nicht
einmal das wird immer funktionieren
Denn:
Ich habe hier noch ein zweites Exemplar des ECEQ. Die Signale sehen
an den meisten Rastpunkten so aus wie in eceq-real.png, aber nicht an
allen.
4 der 32 Rastpunkte liegen nämlich wie im Datenblatt tatsächlich fast
genau auf einer der Flanken von B. An diesen Rastpunkten nimmt das
B-Signal zufällig einen der Werte 0 oder 1 an, und durch leichtes
Rütteln am Drehknopf lässt sich dieser Wert sogar ändern, ohne den Knopf
wirklich zu drehen. 3 weitere der 32 Rastpunkte liegen sogar auf der
linken Seite der B-Flanke.
Das alles äußert sich letztendlich darin, dass der Zähler beim Drehen um
eine Raste manchmal unverändert bleibt und dafür bei der nächsten Raste
gleich zweimal inkrementiert bzw. dekrementiert wird. Da in ein und
demselben Encoder alle drei Fälle auftreten (Rastpunkt rechts von, auf
oder links von der B-Flanke), lässt sich das Problem auch mit noch so
raffinierten Softwaretricks nicht beheben.
Fazit:
Man muss sich für eine der folgenden beiden Alternativen entscheiden:
1. Man nimmt einen Encoder, dessen Rastpunkte auf (oder nahe bei) den
Flanken eines der beiden Signale liegt, implementiert den klassischen
Auswertealgorithmus und nimmt in Kauf, dass der Zählerstand am
Übergang zwischen zwei Rastpunkten u.U. flattert. Das ist zwar ein
Schönheitsfehler, aber ansonsten funktioniert die Sache bestens.
2. Oder man nimmt einen Encoder, dessen Rastpunkte (vom Hersteller so
spezifiziert) zwischen den Signalflanken liegen, wertet die Signale
mit Hysterese aus und hat damit eine Lösung, die ebenfalls bestens
funktioniert und zudem den genannten Schönheitsfehler nicht hat.
Auf gar keinen Fall sollte man aber den Encodertyp aus (1) mit dem
Auswertealgorithmus aus (2) kombinieren. Das ist – um es mit den Worten
von Thomas auszudrücken (ich selber benutze solche Termini normalerweise
nicht) –
Thomas E. schrieb:> Bullshit
Ach Yalu,
du hast es immer noch nicht geschafft. Wahrscheinlich schafft es
NIEMAND, den Leuten klar zu machen, wie es geht, denn die wollen einfach
nicht zuhören und sind eher an Zoff und Gelaber interessiert als an
einer sachlichen Belehrung. Nicht traurig sein..
So, und für alle diejenigen, die es immer noch nicht gerafft haben, aber
dennoch an einem Ergebnis interessiert sind, hier der passende Tip:
W.S. schrieb:> Na, ich versuch's mal:
Was soll man da machen, außer sich selbst zu zitieren...
W.S.
W.S. schrieb:> Ach Yalu,> du hast es immer noch nicht geschafft. Wahrscheinlich schafft es> NIEMAND, den Leuten klar zu machen, wie es geht, denn die wollen einfach> nicht zuhören und sind eher an Zoff und Gelaber interessiert als an> einer sachlichen Belehrung. Nicht traurig sein..>> So, und für alle diejenigen, die es immer noch nicht gerafft haben, aber> dennoch an einem Ergebnis interessiert sind, hier der passende Tip:> W.S. schrieb:>> Na, ich versuch's mal:>> Was soll man da machen, außer sich selbst zu zitieren...>> W.S.
Ach je. Das haben wir schon immer so gemacht und anders geht das nicht
und immer wieder gibt es Idioten, die meinen, das besser zu können. Und
NIEMAND schafft es, diesen Idioten klar zu machen, wie blöde sie doch
sind.
Ja ja. Und deswegen freuen wir uns immer wieder, dass der Zähler hin und
her wackelt. Da haben wir uns ja schliesslich schon immer drüber
gefreut.
Weisst du, was ich an Leuten wie dir besonders schätze?
mfg.
Thread beobachten
Seitenaufteilung abschalten
