Guten Abend, ich habe einen Inkrementalgeber an einen Arduino Nano angeschlossen (s. Anhang). Das ganze habe ich einmal ohne und einmmal mit den 10 nF Kondensatoren (C1 und C2). Die Pins D2 D3 und D4 vom Arudino habe ich anschließend mit einem Logic Analyzer ausgelesen. Dabei kam heraus, dass auch bei dem Aufbau ohne Kondensatoren kein Prellen auftritt (s. Anhang). Ist das gewöhnlich / ungewöhnlich oder habe ich irgendwas übersehen / nicht beachtet?
Angehängte Dateien:
-
Scematics.PNG
9,2 KB -
Mit_Kondensator.PNG
17 KB -
Ohne_Kondensator.PNG
16 KB
Rotary schrieb: > oder habe ich irgendwas übersehen nicht beachtet? deine Abtastrate ist nur 800Hz, oder? es kann sein, dass das Prellen zwischen deinen Abtastpunkten stattfindet.
Das hängt doch davon ab, nach welchem Prinzip der Geber arbeitet. Hat der wirklich mechanische Kontakte, oder wird da etwas elektronisch abgetastet (optisch, magnetisch, ...)
Einerseits sampelst Duda Recht langsam mit den 800 Hz, andererseits könntest du da auch einen optischen Encoder haben der prinzipiell nicht prellen kann.
Hier wurde häufig berichtet, das Inkrementalgeber frühzeitig ausfallen, wenn die Entprellung nicht gut gemacht wurde. Offenbar steigt das Prellen mit dem Alter an.
Stefan ⛄ F. schrieb: > Offenbar steigt das Prellen mit dem Alter an. Das kenne ich auch so und die Erfahrung mit Tastern zeigt das auch. Noch kann es gut gehen, vielleicht geht es auch in zehn Jahren noch gut, aber vielleicht funktioniert es in zehn Jahren auch nicht mehr.
Beitrag #6310482 wurde von einem Moderator gelöscht.
Rotary schrieb: > Dabei kam heraus, dass auch bei dem Aufbau ohne > Kondensatoren kein Prellen auftritt (s. Anhang). Ist das gewöhnlich / > ungewöhnlich oder habe ich irgendwas übersehen / nicht beachtet? Ein Inkrementalgeber liefert einen 2-Bit Gray-Code. Prellen stört die Auswertung nicht, solange du nicht langsamer abfragst, als für die Drehgeschwindigkeit erforderlich.
Rotary schrieb: > habe ich irgendwas übersehen Du würdest mit deinem Digitalscope Prellen im Mikrosekunden bis Millisekundenbereich sowieso nicht mitbekommen, weil deine Anzeige dasselbe tut wie die korrekte Auswertung eines Incrementalgebers tun würde: nur mit einer Samplefrequenz abtasten. Die Kondensatoren und Widerstände davor sind überflüssig, wenn die Software auf dem uC den korrekten Auswertealgorithmus verwendet. https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 Ein mechanischer Kontakt wird immer prellen, aber das kann bei guten Kontakten im sub-Mikrosekundenbereich passieren, bei schlechten ein Kratzen über die ganze Kontaktfläche sein.
Angehängte Dateien:
-
entprellung.png
49 KB
Die Zeitkonstante des RC-Glieds für die Entprellung ist sowieso sehr knapp bemessen. Schon ein Kontakthüpfer von nur 60µs Dauer kann am AVR-Eingang schon zu einem Fehlimpuls führen (s. Anhang). Aber wie andere schon geschrieben haben, brauchst du das RC-Glied bei richtiger Auswertung durch die Software gar nicht.
Yalu X. schrieb: > Die Zeitkonstante des RC-Glieds für die Entprellung ist sowieso sehr > knapp bemessen. Schon ein Kontakthüpfer von nur 60µs Dauer kann am > AVR-Eingang schon zu einem Fehlimpuls führen (s. Anhang). Schön deutlich machende Simulation.
Ist das RC so überhaupt realistisch? Was hat der Eingang für eine reale Kapazität und Rin? Haben die nicht auch noch parallele parasitäre R und C durch clamp Dioden?
>Ist das RC so überhaupt realistisch? Was hat der Eingang für eine reale >Kapazität und Rin? Haben die nicht auch noch parallele parasitäre R und >C durch clamp Dioden? Ja, aber in ganz anderen Größenordnung, die hier eher irrelevant ist.
Ganz so irrelevant ist das nicht. Ich hatte mal einen high-speed-GEber für Maschinen, der mit 10kHz Pulse lieferte. Um die Dynamik auszurechnen, musste mit wenigen Schritten Verzögerung die Beschleunigung gemessen werden. Da waren maximal 5 Werte beteiligt und die so entstehende Zeit von 200us musste auf 10bit genau gerechnet werden. Daher braucht es genaue Flanken, wegen Störungen und so. Da macht das schon einen Unterschied.
Jens U. schrieb: > Ganz so irrelevant ist das nicht. im Verhältnis zu den externen 10nF und 10kOhm sind die parasitären Eigenschaften des Eingangs zu 100 Prozent irrelevant - die gehen in der Toleranz der externen Komponenten unter.
> Prellt ein Inkrementalgeber immer ?
Nicht immer, aber immer öfter. Insbesondere, wenn man dran dreht.
Angehängte Dateien:
-
Ohne_C_Zoom_2.PNG
34 KB -
Mit_C_Zoom_2.PNG
21 KB
Moin zusammen, vielen Dank schon mal für die ganzen Anregungen. Ich habe das Ganze nochmal mit gleicher Samplingrate und deutlich häher abgetastet (war gesttern etwas Zeitstress, hatte das total übersehen). Das Eute ist, das kein Prellen zwischend den beiden Terminals eingestreut wird. Allerdings findet gelegentlich ein Prellen beim Schließen und Öffnen der Kontakte statt. Meint ihr ich sollte die Widerstände besser auf 5 kOhm ändern um so die Zeitkonstante von 500 µs auf 250 µs zu senken? Die beiden Anhänge zeichen die Logic-Messung bei 10 Mhz. Einmal mit Kondensatoren, einmal ohne Kondensatoren. Wichtig, es handelt sich dabei um den gleichen, jedoch nicht selben Inkrementgeber.
Rotary schrieb: > Allerdings > findet gelegentlich ein Prellen beim Schließen und Öffnen der Kontakte > statt. Klar: Prellen findet jeweils beim Umschalten der Kontakte statt. Rotary schrieb: > Meint ihr ich sollte die Widerstände besser auf 5 kOhm ändern um > so die Zeitkonstante von 500 µs auf 250 µs zu senken? Es wurde inzwischen schon oft geschrieben: wenn deine Software den Drehgeber "sauber" auswertet, dann kannst du dir die RC-Tiefpässe vollständig sparen. https://www.mikrocontroller.net/articles/Drehgeber
Hi Achim, ja das stimmt das wäre möglich. Aber es handelt sich um ein kleines Schulprojekt. Die späteren Arduinos werden später ggf. umprogrammiert. Dabei kann es dann passieren, dass dabei die eine programmierte Hytserese überschrieben wird. Daher würde ich lieber das Signal hardwareseitig entprellen als das später in der Software herauszufiltern.
Rotary schrieb: > Die späteren Arduinos werden später ggf. umprogrammiert. Grade dann würde ich Wert darauf legen, dass die Programmierung der Auswertung immer sauber gemacht wird. Denn es ist nicht schwerer, die Software für die Auswertung der Drehgeber sauber zu programmieren. Man muss es nur einmal erklärt bekommen, dann kann man es in Zkunft immer richtig machen. Wenn du großen Wert darauf legst, die Entprellung per RC-Tiefpass zu machen, dann miss noch ein paar mal nach, wie lange ohne C das längste Prellen ist, das du findest. Und dann dimensioniere RC so, dass die Zeitkonstante deutlich über der Länge dieses Prellens liegt.
Ups, ich habe ungeschickt zitiert. Eigentlich wollte ich sagen: grade wenn es sich um ein Schulprojekt handelt würde ich Wert darauf legen, dass die Auswertung der Drehgeben immer sauber gemacht wird.
Inkrementalgeber (wie auch Tasten, Schalter oder Lichtschranken) prellen immer und zwar sowohl beim Schließen als auch beim Öffnen des Kontaktes. Tasten wie sie in Tastaturen verbaut sind, prellen bis zu 3 ms lang, wobei sich die Prelldauer mit dem Alter der Kontakte vergrößert, da die Kontaktflächen dann nicht mehr glatt sind. Optische "Kontakte" prellen auch, da der Lichtstrahl einen Durchmesser hat und die Abdeckung (wie bei einem Sonnenauf- oder - untergang) nicht spontan erfolgt. So entsteht immer eine Rampe mit einem Bereich, wo die Zustände "hell" und "dunkel" nicht eindeutig sind und schon leichtes Rauschen (der Helligkeit oder des elektrischen Signals) ein Pendeln zwischen den Zuständen verursacht. Abhilfe schafft bei der Erkennung das Einführen einer Hysterese (SchmittTriggerEingang). Der ist auch nötig, wenn man mechanische Kontakte mit RC-Gliedern (wie im Bild oben) "geglättet" hat. Denn auch da wird die Entladekurve (durch das Schließen des Schalters) beim Prellen durch kurze Aufladestücke unterbrochen. Wenn das gerade auf der Schwelle zwischen High- und Low-Pegel erfolgt, prellt das Signal trotz RC-Glied. Einfache Lösung: Einfügen eines Schmitt-Triggers (bei Lichtschranken direkt, bei mechanischen Schaltern nach einem RC-Glied). Etwas aufwändiger (aber für Mengenproduktion billiger): Entprellung per Software. Aber dann muss man die Randbedingungen - welche maximale Impulsfolge ist zu erwarten und wie lange prellt der hier verbaute Schalter (auch nach ein paar Jahren) - genau kennen.
Rotary schrieb: > Meint ihr ich sollte die Widerstände besser auf 5 kOhm ändern um so die > Zeitkonstante von 500 µs auf 250 µs zu senken? Nein. Du scheinst wirklich maximal merkbefreit und lernresistent zu sein.
Rotary schrieb: > Daher würde ich lieber das Signal hardwareseitig entprellen als das > später in der Software herauszufiltern. Die Software muss da nichts filtern. Die muss einfach nur den Gray-Code sauber auswerten.
Rotary schrieb: > Aber es handelt sich um ein kleines Schulprojekt. Vielleicht sollte sich Deine Schule mal an einen Fachmann wenden.
MaWin schrieb: > Nein. > Du scheinst wirklich maximal merkbefreit und lernresistent zu sein. Sorry. War ein Denkfehler, ich meinte natürlich die Zeitkonstante erhöhen durch höhere Widerstände. Achim S. schrieb: > Grade dann würde ich Wert darauf legen, dass die Programmierung der > Auswertung immer sauber gemacht wird. Denn es ist nicht schwerer, die > Software für die Auswertung der Drehgeber sauber zu programmieren. Die Entprellung softwareseitig habe ich drin und funktioniert auch. Dennoch will ich als Schutz vor Codeänderung wie schon gesagt das ganze HW-seitig realisieren. Achim S. schrieb: > Wenn du großen Wert darauf legst, die Entprellung per RC-Tiefpass zu > machen, dann miss noch ein paar mal nach, wie lange ohne C das längste > Prellen ist, das du findest. Und dann dimensioniere RC so, dass die > Zeitkonstante deutlich über der Länge dieses Prellens liegt. Jep, so werd ich es auch erstmal machen, danke dir !
Ich fürchte, dass der Hinweis auf den Gray-Code für jemanden, der sich damit nicht gut auskennt, eher verwirrend wirkt. Daraus abzuleiten, ob nur aufwärts oder abwärts gezählt werden muss, schafft ein Programmierer mit wenig Erfahrung üblicherweise nicht - auch wenn das für einen Profi extrem simpel erscheint. Mehr Nachsicht (oder viel mehr Erklärung) dem "Nachwuchs" gegenüber. Wir haben auch mal angefangen und waren da alles andere als perfekt. (Wir erinnern uns nur nicht mehr so ganz gern an unsere Anfänge....)
Günni schrieb: > Ich fürchte, dass der Hinweis auf den Gray-Code für jemanden, der sich > damit nicht gut auskennt, eher verwirrend wirkt. Daraus abzuleiten, ob > nur aufwärts oder abwärts gezählt werden muss, schafft ein Programmierer > mit wenig Erfahrung üblicherweise nicht - auch wenn das für einen Profi > extrem simpel erscheint. Mehr Nachsicht (oder viel mehr Erklärung) dem > "Nachwuchs" gegenüber. Wir haben auch mal angefangen und waren da alles > andere als perfekt. (Wir erinnern uns nur nicht mehr so ganz gern an > unsere Anfänge....) Danke. Schön zu hören wenn es auch User im Forum gibt, die dafür Verständnis haben. Ich habe aktuell noch zwei Fragen offen: 1.Wie berechent sich genau die Zeitkonstante in diesem Fall. Werden können die beiden Widerstände trotz dem Schalter einfach zusammengefasst werden? 2. Das längste Prellen dauert in etwa 0,5 µs. Das liegt doch in jedem Fall unter der Zeitkonstante des RC Glieds, wieso treten diese dann überhaupt auf?
Mechanische Drehgeber prellen immer. Welchen Drehgeber hast du denn?
Rotary schrieb: > 2. Das längste Prellen dauert in etwa 0,5 µs. Das liegt doch in jedem > Fall unter der Zeitkonstante des RC Glieds, Für mich sieht deine Messung Ohne_C_Zoom_2.png so aus, als wäre es locker ein Faktor 1000 länger. Rotary schrieb: > Danke. Schön zu hören wenn es auch User im Forum gibt, die dafür > Verständnis haben. Na was denn nun? Brauchst du eine einfachere Erklärung, wie man Drehgeber korrekt auswertet? Oder hast du die korrekte Auswertung verstanden und willst nur dafür Vorsorge treffen, dass auch eine "schlechte" Software damit klar kommt? Du wirst alleine mit RC-Gliedern nicht beliebig sicher verhindern können, dass eine schlechte Software zu einem fehlerhaften Verhalten führt. Rotary schrieb: > 1.Wie berechent sich genau die Zeitkonstante in diesem Fall. Werden > können die beiden Widerstände trotz dem Schalter einfach zusammengefasst > werden? Nö. Rechne nur mit dem einen Widerstand. Wobei es auf einen Faktor 2 bei dem Ansatz auch nicht ankommt.
Egal warum wieso, ich würde auf alle fälle deutlich mehr als nur zB. 0,5mA über die Kontakte schicken. 2-5mA sollten es schon sein, um sie sauber zu halten!
Achim S. schrieb: > Rotary schrieb: >> 2. Das längste Prellen dauert in etwa 0,5 µs. Das liegt doch in jedem >> Fall unter der Zeitkonstante des RC Glieds, > > Für mich sieht deine Messung Ohne_C_Zoom_2.png so aus, als wäre es > locker ein Faktor 1000 länger. Und wie schön, dass das von Rotary angegebene Datenblatt sogar was dazu sagt: "Contact Bounce (15RPM)....2.0 ms maximum"
Achim S. schrieb: > Du wirst alleine mit RC-Gliedern > nicht beliebig sicher verhindern können, dass eine schlechte Software zu > einem fehlerhaften Verhalten führt. Das kann selbst bei Drehgebern passieren, die aus technischen Gründen nicht prellen, z.B. optische - wenn der Geber zufällig genau am Übergang von einem Schritt zum nächsten steht, können schon geringste Störungen dazu führen, dass der Geberausgang um diesen Übergang hin und her springt. Einer korrekten Gray-Code-Auswertung macht das nichts, weil abwechslend +1 und -1 gezählt wird, es entsteht also kein dauernder Fehler. Und weil dieses Springen zeitlich nicht begrenzt ist nützt ein RC-Glied überhaupt nichts. An einer richtigen Auswertung der Quadratursignale führt einfach kein Weg vorbei, auch wenn das hier immer wieder behauptet wird. Prellzeiten von 0,5 µs sind einfach Blödsinn - entweder prellt der Schalter viel länger oder garnicht. Georg
Rotary schrieb: > Die späteren Arduinos werden später ggf. umprogrammiert. Du willst also kindersixhere Hardware entwickeln.
Rotary schrieb: > Logic Analyzer Im Kaufhaus gibt es so schöne Werkzeug-Sets für Kinder im Vorschulalter. Vielleicht solltest Du Dir die disfunktionalität solcher Geräte mal eindringlich vor Augen führen bevor Du eine Bohrmaschine in die Hand nimmst.
Stefan ⛄ F. schrieb: > Hier wurde häufig berichtet, das Inkrementalgeber frühzeitig ausfallen, > wenn die Entprellung nicht gut gemacht wurde. Offenbar steigt das > Prellen mit dem Alter an. So ist es. Neue Encoder arbeiten an schlechter Entprellung exakt so lange, bis die Gewährleistung abgelaufen ist. Man könnte aber auch sagen, die Kontakte oxydieren, die Federspannung läßt nach, das Schmierfett verhärtet, Staub dringt ein.
Rotary schrieb: > Die Pins D2 D3 und D4 vom Arudino habe ich anschließend mit einem Logic > Analyzer ausgelesen. Dabei kam heraus, dass auch bei dem Aufbau ohne > Kondensatoren kein Prellen auftritt (s. Anhang). Ist das gewöhnlich > ungewöhnlich oder habe ich irgendwas übersehen nicht beachtet? Du hättest besser erstmal Physik studiert. Rotary schrieb: > Die Pins D2 D3 und D4 vom Arudino habe ich anschließend mit einem Logic > Analyzer ausgelesen. So hast Du jetzt Dein Gehirn falsch verdrahtet... Benedikt D. schrieb: > Erstmal: ich bin neu hier. Hab Elektrotechnik mit analoger und digitaler > Schaltungstechnik studiert, bin aber ehrlich gesagt seit Jahren mehr im > Vertrieb als in der Entwicklung tätig ...was deine kleine Krämerseele zu Fehlschlüssen geführt hat nachdem Du sie geweckt hast.
Angehängte Dateien:
-
ohne_C.PNG
36 KB -
ohne_C_-_Zoom.PNG
38 KB
Achim S. schrieb: > Oder hast du die korrekte Auswertung > verstanden und willst nur dafür Vorsorge treffen, dass auch eine > "schlechte" Software damit klar kommt? Genau um das geht es mir Achim und ich würde dazu gerne verstehen, wieso trotzdem ein gewisses Prellen (s. Anhang) auftritt, trotz RC-Glied mit Tau = 500.00 µs. Die intepretation des Greycodes funktioniert schon länger und der Inkrementgeber funktioniert damit auch tadellos. Dennoch würde ich eben auch gerne die Hintegründe des Prellens verstehen. Ich denke an der Stromstärke liegt es im übrigen nicht, ein Test mit 100nf und 1 kOhm zeigte dad gleiche Verhalten.
Rotary schrieb: > Genau um das geht es mir Achim und ich würde dazu gerne verstehen, wieso > trotzdem ein gewisses Prellen (s. Anhang) auftritt, trotz RC-Glied mit > Tau = 500.00 µs. wegen Dietrich L. schrieb: > "Contact Bounce (15RPM)....2.0 ms maximum" Und bist du sicher, dass dein LA sich bezüglich Hysterese und Schaltschwellen genauso wie dein Controller verhält, oder wo greifst du die Signale für den LA ab?
Rotary schrieb: > wieso trotzdem ein gewisses Prellen (s. Anhang) auftritt, trotz RC-Glied > mit Tau = 500.00 µs. du benennst den Anhang "ohne C" aber er wurde mit RC aufgenommen? und hast jetzt womöglich hinter dem R (nicht wie bei den früheren Messungen davor)? Keine gute Wahl des Namens für die Messung. Rotary schrieb: > Dennoch würde ich eben auch gerne die Hintegründe des Prellens > verstehen. dann miss die flanke auch Mal mit einem oszi und überlege, warum der LA (der wahrscheinlich keine Hysterese hat) keinen stabilen Pegel erkennt.
Wolfgang schrieb: > "Contact Bounce (15RPM)....2.0 ms maximum" Das bedeutet doch lediglich, dass das Prellen maximal 2 ms lang ist. Mein gemessenes Prellen ist lediglich wenige Mikrosekunden lang. Durch mein RC Glied sollten Pulse („Frequenzen“) von wenigen ms doch rausgefiltert werden. Wenn mein Prellen jetzt 1 ms groß wäre, dann würde ich das ja verstehen. > Und bist du sicher, dass dein LA sich bezüglich Hysterese und > Schaltschwellen genauso wie dein Controller verhält, oder wo greifst du > die Signale für den LA ab? An den digitalen Pins des Arduino. Ich habe den Aufbau eben einmal so abgeändert, dass die Signale nicht am Arduino anliegen und nur vom LA ausgelesen werden. Und sieh da, keine Prellen im Mikrosekundenbereich. Der Messung nach liegt hier also die Ursache für die Störungen.
Achim S. schrieb: > Rotary schrieb: >> wieso trotzdem ein gewisses Prellen (s. Anhang) auftritt, trotz RC-Glied >> mit Tau = 500.00 µs. > > du benennst den Anhang "ohne C" aber er wurde mit RC aufgenommen? und > hast jetzt womöglich hinter dem R (nicht wie bei den früheren Messungen > davor)? Keine gute Wahl des Namens für die Messung. > > Rotary schrieb: >> Dennoch würde ich eben auch gerne die Hintegründe des Prellens >> verstehen. > > dann miss die flanke auch Mal mit einem oszi und überlege, warum der LA > (der wahrscheinlich keine Hysterese hat) keinen stabilen Pegel erkennt. Ach du hast recht, da habe ich die falsche Datei hochgeladen, das Prellen beim Umschalten (Anhang 2) tritt jedoch beim Umschalten mit als auch ohne C auf.
Rotary schrieb: > Ach du hast recht, da habe ich die falsche Datei hochgeladen, das > Prellen beim Umschalten (Anhang 2) tritt jedoch beim Umschalten mit als > auch ohne C auf. du siehst die Interpretation des LA deiner langsamen Flanke. dein Controller interpretiert ggf. etwas anderes. miss mit einem Oszilloskop, dann siehst du klarer.
MaWin schrieb: > Du scheinst wirklich maximal merkbefreit und lernresistent zu sein. Die Grenzen der Physik lassen sich nirgends besser studieren als in der Grundi und wo Du es grade ansprichst kann man sich mit Ignoranz ganz schön den Verstand versauen und nach dem Abgang des Paradebeispiels Kurt sind hier immer mehr Figuren aufgetaucht die sich nach allen Regeln der Kunst den Verstand versaut haben. Mit dem Internet geht natürlich nicht nur Alles viel besser sondern ist sogar die unverrückbare Folge. ;-)
Rotary schrieb: > Achim S. schrieb: >> Oder hast du die korrekte Auswertung >> verstanden und willst nur dafür Vorsorge treffen, dass auch eine >> "schlechte" Software damit klar kommt? > > Genau um das geht es mir Das halte ich für den grundfalschen Ansatz. Es gibt nur eine Art, den Graycode von einem Drehgeber korrekt auszuwerten. Und die hat kein Problem mit Prellen. Ergo: man muß nicht entprellen. Wenn man den Graycode auf die falsche Art auswertet, dann ist vollkommen erwartbar und aus didaktischen Gründen sogar höchst erwünscht, wenn dabei falsche Ergebnisse herauskommen. > ich würde dazu gerne verstehen, wieso trotzdem ein gewisses Prellen > (s. Anhang) auftritt, trotz RC-Glied mit Tau = 500.00 µs. 1. weil die Prellzeit länger ist. Rotary schrieb: > Mein gemessenes Prellen ist lediglich wenige Mikrosekunden lang Glaube ich nicht. Wenn der Hersteller Prellzeiten von maximal 2ms ankündigt, dann wirst du real zwar weniger sehen, aber nicht Faktor 1000 weniger. Eher Faktor 10. Nach Alterung vielleicht noch Faktor 2. Und 2. weil ein RC-Glied nur in Verbindung mit einem Schmitt-Trigger (mit ausgeprägter Hysterese) entprellt. Die Zeitkonstante muß auch deutlich größer als die Prellzeit sein. Lies es nach: Entprellung: Einfacher Taster > Ich denke an der Stromstärke liegt es im übrigen nicht Natürlich nicht. Das Kontaktprellen ist ein mechanisches Problem (elastischer Stoß).
Stefan ⛄ F. schrieb: > Hier wurde häufig berichtet, das Inkrementalgeber frühzeitig ausfallen, > wenn die Entprellung nicht gut gemacht wurde. Offenbar steigt das > Prellen mit dem Alter an. Was hier häufig berichtet wird, ist nur das ewige Drumherum-Diskutieren als solches. Mach dir deshalb keine Sorgen - es ist immer wieder die gleiche Leier, die mir mittlerweile zum Hals raus hängt. Selbst MaWin kommt mal wieder damit: "weil deine Anzeige dasselbe tut wie die korrekte Auswertung eines Incrementalgebers tun würde: nur mit einer Samplefrequenz abtasten." Jahaha.. man braucht bloß mit einer exakt zum Drehen des Encoders passenden Samplefrequenz abzutasten und schon sind alle Probleme beseitigt. Prinzipiell ist das ja auch völlig richtig - man muß bloß denjenigen, der an dem Ding dreht, davon überzeugen, daß er passend schnell zur Samplefrequenz zu drehen hat. Die Steigerung folgt auf dem Fuße: "Die Kondensatoren und Widerstände davor sind überflüssig, wenn die Software auf dem uC den korrekten Auswertealgorithmus verwendet." Na klar, man braucht keine Hochzieher, weil ein Schaltkontakt zusammen mit einem Pullup-Strom aus dem Portpin ja ausreicht und das zusammen mit der Schaltkapazität der Leitungen hin zum Drehdingens nen ausreichenden Tiefpaß bildet - was wiederum rein theoretisch völlig exakt ist und theoretisch deshalb auch funktionieren würde. Aber: Die Praxis sagt was ganz anderes: Zum einen soll ein Kontakt einen gewissen Mindest-Strom abkriegen, um sauber zu schalten. Zum anderen sollen Inputs zum µC hin nicht unnötig hochohmig gemacht werden, um Einstreuungen entgegenzuwirken. Zum dritten sollen aus gleichem Grunde Inputs auch sinnvoll in ihrer Bandbreite begrenzt werden, also nen Kondensator dran wo es Sinn macht. Beispiel: Ich habe neulich meine tolle 80€ Funkmaus auseinandergenommen, weil das Scrollrad nur noch Mist geliefert hat. Da ist ein ganz kleiner Drehencoder drin, billigster aber winziger Aufbau, ein Blech-Formwinkel, darin ein drehbares Plastikformstück, drei winzige verzinnte Büchsenblech-Kontakte, die von dem Plastikstück aufeinander gedrückt werden oder eben nicht. Kein schleifender Kontakt, sondern zusammendrückende Funktion. Keinerlei Edelmetall (sprich Vergoldung) unter'm Stereomikro sichtbar. Natürlich wird dieser Drehgeber mit dem geringstmöglichen Querstrom betrieben (weil aus Batterie gespeist) und durch die Oxidation der Kontaktstücke gibt es dann nach ein paar Jahren nur noch gelegentlich mal nen tatsächlichen Kontakt. Zum Putzen kommt man an die Innereien dieses Kunstwerkes nicht heran (oder man riskiert, daß die umgebogenen Nasen des Blechwinkels abbrechen und man dann die A-Karte gezogen hat). Ich wollte auch nicht mit Zeugs wie Ballistol, WD40 und Konsorten an sowas heran. Also hab ich das Ganze "elektrisch" geputzt: mal nen Querstrom von so etwa 100 mA aus dem LNG drauf, Rädchen gedreht, gedreht... und siehe da, die Maus tut es wieder prächtig. Fazit: für eine lange Lebensdauer ist gerade bei billigen Zinnkontakten ein gewisser Mindest-Kontaktstrom wichtig. Ob der nun statisch geliefert wird oder aus der Entladung von einem 22nF herkommt, ist wahrscheinlich völlig schnurz. W.S.
Angehängte Dateien:
-
SCRN0573.PNG
8,4 KB
Naja, das mit dem Hardwarefilter an einem Drehgeber sollte man ggf. mal überdenken. Anbei ein Bild aus der Praxis. Signal oben: Direkt am Drehgeber, 10k Pull Up Signal mitte: Nach RC-Filter 10k+100nF Signal unten: Nach 74HC14 Schmitt-Trigger. Der Drehgeber ist ein Wald- und Wiesen Typ, ich glaube von Alps
Hallo, der EC12E ist von Alps und hat mechanische Kontakte. Stört aber alles nicht wenn man die Signale richtig auswertet, dann können die prellen wie sie wollen. https://www.mikrocontroller.net/articles/Drehgeber Ein von Hand bedienter kann auch per Polling abgefragt werden, dabei muss es nicht unbedingt mit Timer sein.
Hallo, ich möchte nochmal ernsthaft nachfragen ob ihr W.S. und Falk immer einen Tiefpass an I/O Pins baut woran ihr einen mechanischen Kontakt anklemmt? Ich stehe zwischen den Stühlen. Auf der einen Seite funktioniert der Code von Peter auch mit meinen billigsten Alps Encodern einwandfrei und auf der anderen Seite kann ich mir aktuell nicht vorstellen das man immer einen zusätzlichen R, C und Schmittrigger auf die Platine baut und das für jeden benötigten Pin. Welchen Aufwand treibt ihr in der Praxis wirklich?
Veit D. schrieb: > Welchen Aufwand treibt ihr in der Praxis wirklich? Mal so, mal so. Ja, die Standardauswertung aus dem Wiki ist sehr robust und funktioniert auch ohne RC-Filter, nutze ich auch in vielen Aufbauten und die funktionieren alle zuverlässig. Den Schmitt-Trigger gibt es beim AVR kostenlos dazu, denn der ist in allen IOs mit drin.
Veit D. schrieb: > kann ich mir aktuell nicht vorstellen das man > immer einen zusätzlichen R, C und Schmittrigger auf die Platine baut Da die Eingänge vom AVR bereits Schmitt-Trigger enthalten, fällt zumindest dieses Bauteil weg. Aber eben nur bei AVR. Ich habe bisher immer R/C Tiefpässe verwendet, weil ich zu faul war, eine Entprellung zu programmieren. Per Software zu entprellen ist aber eleganter, das muss auch ich zugeben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.