Diskussion:Drehgeber

Entprellen (2013)

Woher kommt die Vorstellung, man müsse Drehgeber nicht entprellen? Der Graycode alleine löst das Problem nicht. Entprellt man nicht durch eine Hysteresefunktion in irgendeiner Weise, springt der Wert schnell vor und zurück. Zumindest eine softwaremässige Entprellung muss realisiert werden.

Ich würde sagen, dass genau dies gemeint ist, nämlich dass keine hardwaremässige Entprellung nötig ist :-)

SAM vs. Andreas (2004)

SAM 1

Die Codeform am Ausgang hat nix damit zu tun ob entprellt werden muss, oder nicht. Vielmehr der Unterschied zw. mechanischen und optischen Drehcodierern. Erstere prellen sehr wohl. Letztere prellen nicht, machen sich aber mit ca. 30EUR gegenüber ca. 3EUR(mech.) unbeliebt. Die Auswertung über Timerinterrupt finde ich auch eher unpraktisch. erstens fällt das schon fasst unter Polling und es beansprucht auch die CPU wenn der Drehgeber nix liefert. Flankengesteuerte Interrupts werden der Anforderung wohl eher gerecht. Gekoppelt mit Timerinterrupts kann man dann auch mühelos mechanische Drehgeber entprellen.

Gruß, SAM.

Andreas 1

Solange nicht beide Ausgänge gleichzeitig prellen sollte das Prellen kein Problem sein. Die Auswertung im Timerint. hat den Vorteil dass das Laufzeitverhalten eher voraussagbar ist als bei Flankeninterrupts (bei denen man ohne Totzeit viel eher Probleme mit dem Prellen bekommt). --Andreas 14:20, 24. Nov 2004 (CET)

SAM 2

Hi, was du mit Flankeninterrupts und Totzeit meinst, mein ich wahrscheinlich damit, dass man Flankeninterrupts mit Timerinterrupts koppelt. Das soll heissen: Man reagiert auf die Flanke eines Eingangs (Flankeninterrupt) und liest die Zustände beider Eingänge nach einer bestimmten Warte-/Totzeit (Timerinterrupt) ein, dadurch hat sich der jeweils prellende Eingang "beruhigt", vorrausgesetzt die Wartezeit ist länger als die max. Prellzeit (testen + messen!). Was mich an der Methode (in der man die beiden Eingänge mit Timerinterrupts abtastet) stört, ist, dass man nicht vorhersagen kann zu welchen Zustand der beiden Eingänge man einliest. Man kann dabei doch sehr wohl in die Prellzeit eines Eingangs kommen und erhält ein falsches Ergebnis. Dieses kann man zwar softwaretechnisch rausfiltern, verliert dabei einen Schritt der Drehbewegung. Nachteil meiner Methode ist, dass es eine Maximalgeschwindigkeit des Drehgebers gibt. Es können aber sehr hohe Drehgeschwindigkeiten durch exaktes Timing der Totzeit erreicht werden. Dadurch kommt man ziemlich nah die absolute Maximalgeschwindigkeit heran, die ja durch die Prellzeit gegeben ist. Soll heißen, Die Eingänge dürfen erst nach dem letzten Prellen ihr Signal ändern.

Deine Methode läuft kontinuierlich, meine nur wenn wirklich benötigt. Das Laufzeitverhalten der beiden Methoden unterscheidet sich des halb. Ein Nachteil deiner Methode ist mir noch aufgefallen: Will man bei dir hohe Drehgeschwindigkeiten erreichen, muss man sehr schnelle Timerinterruptintervalle verwenden, was den uC mit einer höheren Grundrechenlast beansprucht.

(mein) Fazit:Man muss halt von der jeweiligen Anwendung abhängig entscheiden, welche Methode besser ist.

Gruß, SAM (26.11.2004)

Andreas 2

Das wurde schon einige Male diskutiert, siehe:

• [1]
• [2]

--Andreas 14:45, 26. Nov 2004 (CET)

Falk vs. Ivan (2008)

Die folgende Diskussion bezieht sich auf diesen Abschnitt von Ivan:

=== Drehgeber an digitalem Potentiometer mit Up/Down-Schnittstelle ===

Dient ein Drehgeber zur Ansteuerung eines digitalen Potentiometers, so kann auf einen separaten Quadraturencoder-chip verzichtet werden sofern es sich beim Potentiometer um einen Typ mit Up/Down-Schnittstelle handelt wie z.ß. das Digitalpotentiometer MCP401x von Microchip. Diese Potentiometer erhöhen ihren Widerstandswert bei einer fallenden Flanke am U/D-Eingang, nachdem CS auf Low gezogen wurde. Wird CS auf Low gezogen und an U/D eine steigende Flanke erkannt, sodann erniedrigt sich der Widerstandswert. Es genügt daher, eine Datenleitung des Drehgebers mit CS und eine mit U/D zu verbinden um das gewünschte Verhalten am Digitalpotentiometer zu erhalten. (Vgl. Signaldiagramm oben)

Falk 1

Der Hack mit der UP/Down Schnittstelle wurde gelöscht, weil es dem nachfolgenden Text wiederspricht! Das ist so ein Sparvariante! Also RAUS!

Ivan 1

Das ist kein Hack sondern das übliche Vorgehen. Warum glauben Sie, wurden diese Digitalpotentiometer mit genau dieser Schnittstelle entworfen? Genau, wegen der einfachen Anbindung eines Drehgebebers. Bleibt also drin, denn ich mach mir die Mühe das rauszusuchen nicht umsonst. [iwan]

Falk 2

>> Das ist kein Hack sondern das übliche Vorgehen.

Murks ist bisweilen weit verbreitet.

> Warum glauben Sie, wurden diese Digitalpotentiometer mit genau dieser >Schnittstelle entworfen?

Das ist mir relativ egal.

> Genau, wegen der einfachen Anbindung eines Drehgebebers.

Bastlerlösung. Und es ist im Artikel KLAR beschrieben, warum das nix gescheites ist!

> Bleibt also drin, denn ich mach mir die Mühe das rauszusuchen nicht umsonst. >[iwan]

1.) Ich glaube kaum, dass irgendwer den Iwan gebeten hat, seine kostbare Zeit für derartige Recherchen zu opfern. 2.) Ich glaube noch viel weniger, dass jeder X-Belibige Hobbybastler hier seine halbgaren Lösungen kritiklos verbreiten darf.

MFG Falk

Ivan 2

>> Das ist kein Hack sondern das übliche Vorgehen.

> Murks ist bisweilen weit verbreitet.

Gehts noch? Diese Digipots sind, wie ich Dir schon mitzuteilen versuchte, extra für den direkten Anschluß an Drehgeber konzipiert.

>> Warum glauben Sie, wurden diese Digitalpotentiometer mit genau dieser >> Schnittstelle entworfen?

> Das ist mir relativ egal.

Danke, das bestätigt meine Hypothese daß Du einfach lernresistent bist. Sonst hättest Du wenigstens einen Blick in das Datenblatt eines dieser Digital-Potentiometer geworfen. Schau Dir das Signaldiagramm im Datasheet und jenes im mikrocontroller.net-Artikel "Drehgeber" an. Exakt jene Zustandsänderungen, die der Drehgeber ausgibt werden vom Digitalpotentiometer erwartet. Glaubst Du wirklich <Zitat src="Microchip">The simple U/D protocol uses the state of the U/D pin at the falling edge of the CS pin to determine if Increment or Decrement mode is desired...</Zitat> haben die nur aus Zufall implementiert?

>> Genau, wegen der einfachen Anbindung eines Drehgebebers.

> Bastlerlösung.

Ein laut Datenblatt für den Zweck geeignetes IC einzusetzen ist Deiner Meinung nach also eine "Bastlerlösung". Ich zitiere nochmal aus dem Datenblatt: "Subsequent rising edges of the U/D pin move the wiper." Das ist genau die Ausgabe eines Drehgebers!

> Und es ist im Artikel KLAR beschrieben, warum das nix gescheites ist!

Dort hast du lediglich dargelegt, welche Schwachstellen ein auf steigende oder fallende Flanken getriggerter Interrupt an einem Mikrocontroller aufweist.

>> Bleibt also drin, denn ich mach mir die Mühe das rauszusuchen nicht umsonst.

> 1.) Ich glaube kaum, dass irgendwer den Iwan gebeten hat, seine kostbare Zeit > für derartige Recherchen zu opfern.

Ich bin durch Zufall in den Besitz solcher Digitalpotentiometer gekommen. Nach Lektüre der Datenblätter habe ich festgestellt, daß diese bestens zur Auswertung von Drehimpulsgebern geeignet sind. Da mir das Forum dieser Präsenz schon einige Male hilfreich war, habe ich beschlossen meine Erkenntnisse mit der Community zu teilen und daher einen für die Allgemeinheit halbwegs lesbaren und verständlichen vierzeiligen Zusatz im "Drehgeber-Artikel" verfasst.

> 2.) Ich glaube noch viel weniger, dass jeder X-Belibige Hobbybastler hier > seine halbgaren Lösungen kritiklos verbreiten darf.

Und wer bist Du? Schon als Elektronik-Gott der Gebärmutter entschlüpft? Um mit deinen Worten zu sprechen: Ich glaube kaum, dass es hier erwünscht ist, daß gute Tips eines ambitionierten Hobbyelektronikers (nenn' mich ruhig Bastler) mutwillig und dauerhaft von einem (sich selbst anscheinend als Nichtbastler sehenden) "Zeitgenossen" gelöscht werden.

> Ergo. Der Absatz fliegt raus.

Ich vertrete meinen Standpunkt und Du Deinen. Hier werden wir uns anscheinend nicht einig, daher X-Post nach forum/website zur weiteren Diskussion unter Einbeziehung der uC.net-Community.

Mit kollegialem Gruße, Iwan

Stefan

Stefan 12:06, 24. Dez. 2008 (CET):
Die angesprochene Diskussion im Forum läuft unter dem Betreff Mutwillige Löschungen - Artikel "Drehgeber". Bis die Diskussion abgeschlossen ist, bitte ich darum, den Artikel in diesem Punkt "in Ruhe" zu lassen. Danke.

Iwans Fazit

Leider hat auch die von Stefan erwähnte Diskussion nichts gebracht. Es konnte kein Kompromiß gefunden werden. Der Absatz zu "digitalen Potentiometern mit Up/Down-Schnittstelle" wurde wieder gelöscht, da mich Falk sehr verbissen spüren ließ, das er in diesem Artikel keinen Abschnitt über "digitale Potentiometer mit Up/Down-Schnittstelle" duldet. Ich werde das wohl hinnehmen müssen. Danke an Stefan für die Reorganisation dieser Diskussionsseite.

Iwan

Ui, da wurde jemand durch die Entprelldiskussion offenbar verprellt :-)

Erweiterung und Unterscheidung Handbedienung/Maschinenbedienung

Ich bin ja auch für ausfühliche Texte, aber das geht klar in Richtung schwafeln und fabulieren. Jeder, der sich erstmal einen Überblick verschaffen will, wird verwirrt. Ich bin für die Löschung des unnötig aufgeblähten Abschnitts!

MFG Falk

Hallo Falk,

Im Artikel fand sich folgender Kommentar verbunden mit einer Frage: "Das oben gezeigte Signaldiagramm besitzt zwei Codewechsel zwischen den Rastungen. Das ist zwar nicht sonderlich sinnvoll, wird aber von den meisten Drehknöpfen so gemacht. (Warum?)"

Erstmal habe ich diese Frage beantwortet. Dazu gehört auch, erstmal den Sinn der Rastungen zu erklären, was zur Unterscheidung zwischen Handbedienung und maschinengetrieben führt. Zudem fand ich die Aussage "nicht sonderlich sinnvoll" nicht angebracht, wenn eine Vielzahl von Herstellern so verfährt und zudem einen guten Grund dafür hat. Die Ursache hierfür habe ich in meinem Text auch geliefert.

Darüber hinaus habe ich mir viele Diskussionen zu Drehgebern angeschaut. Vielfach preist man da seinen Algorithmus als gut. Andere beklagen sich, dass der Algorithmus bei Ihnen nicht läuft, was der Urheber nicht versteht oder glauben kann. Das liegt mitunter eben daran, dass es unterschiedliche Drehgeber gibt und auch die Anwendungen differieren, so dass ein Algorithmus hier funktioniert aber dort eben nicht. Und genau darauf bin ich eingegangen. Die im Artikel aufgeführten Algortihmen helfen nur denjenigen, die gerade dieselbe Programmiersprache, denselben Compiler und denselben Prozessor benutzen. Darum habe ich versucht, das Verfahren allgemein zu beschreiben. Von daher kann ich "schwafeln und fabulieren" nicht nachvollziehen und würde um konkretere Zitate mit zugehöriger Kritik bitten.

Ich gebe zu, dass die Stelle am Anfang des Artikels unpassend ist. Aber ich wollte hier erstmal nicht in den von anderen geschriebenen Teilen herumpfuschen und habe daher erstmal alles in dem Abschnitt konzentriert, in dem das Thema schon begonnen war. Daher wäre ich auch froh, mit Dir besprechen zu können, wie die Inhalte besser im Artikel untergebracht werden könnten. Ich würde mir dort sogar noch eine Erweiterung durch Andere zur Differenzierung erhoffen. Denn zum Thema gäbe noch sehr viel zu klären, um den Durchblick zu bekommen. Nur eines von vielen Beispielen: unterschiedliche Rastungen auf Seite 8

Gruß -- Fragment 19:44, 3. Mai 2009 (CEST)

Was haltet ihr von diesem Algorithmus?

Angenommen, die beiden Drehgeberausgänge hießen A und B. Sie würden zyklisch abgefragt. Dann würde die Folge <c> Incrementiere Zähler, wenn a<>B Decrementiere Zähler, wenn b=A a=A b=B </c> schon alles bereitstellen, was nötig wäre. Soweit ich es sehe, hätte sie nicht den Nachteil anderer Sparvarianten: Beim Pendeln verfälscht das Zählergabnis nicht und die Auflösung wird nicht beschränkt. Bei gleichzeitigem Wechsel beider Encoderausgänge bliebe der Zähler nach Durchlauf des Folge auf dem gleichen Stand.

Gruß -- Fragment 21:09, 3. Mai 2009 (CEST)

Moin, ich hätte eine kurze Frage zu dem VHDL-Code, bezüglich des "up_down"-Signales. Wenn ich das richtig sehe, wir das ja nur auf High gesetzt, wenn sich entweder a_in von a _old ODER b_in von b_old unterscheidet. Aber das ist ja nur für den Zeitraum von maximal einer Taktlänge der Fall. Wenn man das ganze nun recht hochfrequent abtastet, erhält man ja nur Pieks mit einer zeitlänge von T_abtast, oder nicht? Liegt es nicht im Interesse, dass 'up_down' für eine bestimmte Drehrichtung permanent auf High ist?