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
:
Bearbeitet durch Moderator
Joa... Und welchen Drehgeber nehm ich am besten dafür?
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.
:
Bearbeitet durch User
Und zum zweiten Problem? Rastung auf der Flanke oder dem Pegel?
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.
Wie sieht denn deiner Meinung nach eine ordentliche Auswertung aus? Endlosschleife oder per Interrupt?
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.
:
Bearbeitet durch User
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ässt Sven 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.
@jens: Würdest du dich mal bei mir melden? Wär super! pi@mailman.no-ip.biz
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...
Mit Schrittmotor, Interrupt und Dynamik. Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR" Kein Prellen, Pendeln, Flattern, Zwitschern, ...
Bezüglich der Hardwareentprellung zur Entlastung des µC gibt es hier eine kleine aber effektive Lösung: http://www.forum-raspberrypi.de/Thread-drehimpulsgeber-inkrementalgeber-entprellen
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 ;-)
:
Bearbeitet durch Moderator
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?
:
Bearbeitet durch Moderator
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".
:
Bearbeitet durch User
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
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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 |
9 | |
10 | 000000000000001111111111111111111122222222222222 <- deine Zählung |
11 | ——————————————————————————————————————————————————> |
Wenn man so viel mehr Impulse hat, als man braucht, dann kann man das so machen, auch mit den Pollin-Encoder.
:
Bearbeitet durch User
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.29 W.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.
:
Bearbeitet durch User
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
Tasten entprellen und Drehencoder scheinen offensichtlich ein weit verbreiteter Fetisch zu sein...
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.
:
Bearbeitet durch Moderator
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
Wolfgang schrieb: > Trotzdem ist man nicht vor einem sporadischen Zählerstandsänderungen auf > dem Rastpunkt sicher, Genau so ist es.
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:
1 | #define ENCPIN0 (PINB & (1 << 0))
|
2 | #define ENCPIN1 (PINB & (1 << 1))
|
3 | |
4 | signed char Encoder(void) |
5 | {
|
6 | static unsigned char encreg = 0; |
7 | unsigned char pins = 0; |
8 | signed char res = 0; |
9 | |
10 | if(ENCPIN0) pins = 1; |
11 | if(ENCPIN1) pins += 2; |
12 | |
13 | if(!pins) //00 |
14 | {
|
15 | if((encreg) == 1) res = -1; else if((encreg) == 2) res = 1; |
16 | encreg = 0x10; |
17 | }
|
18 | else if(pins == 0x03) //11 |
19 | {
|
20 | if((encreg) == 0x11) res = 1; else if((encreg) == 0x12) res = -1; |
21 | encreg = 0; |
22 | }
|
23 | else if(!(encreg & 0x03)) encreg |= pins; //01, 10 |
24 | return res; |
25 | }
|
mfg.
:
Bearbeitet durch User
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: > >
1 | > [ironie on] hier steht dann im vorbildlich kommentierten Code alles was man braucht [ironie off] |
2 | >
|
mfg.
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:
1 | unsigned char odd[] = {0x01, 0x03, 0x00, 0x02}; |
2 | |
3 | if(ENCPIN0) pins = 1; |
4 | if(ENCPIN1) pins += 2; |
5 | pins = odd[pins]; |
6 | ...
|
mfg.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
eceq-datasheet.png
16 KB -
eceq-real.png
4,3 KB
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
Bitte 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.