Hallo,
ich hab vor Jahren mal bei Pollin den Encoder Alps 502
(http://www.pollin.de/shop/dt/MjA2OTU3OTk-/Bauelemente_Bauteile/Passive_Bauelemente/Potis_Trimmer_Encoder/Encoder_ALPS_502.html)
mitbestellt und dann rumliegen lassen weil ich ihn nicht gleich
brauchte. Jetzt hab ich versucht ihn mit einem Arduino auszulesen uns
festgestellt, dass er nicht dem üblichen A/B-Graycode benutzt. Leider
habe ich im Netz auch nichts über ihn gefunden und musste raten wie er
funktioniert.
Anscheinend funktioniert er folgendermaßen: beim Drehen in eine Richtung
bleibt ein Pin-Kontakt immer offen, während der andere für jede
Rasterung einmal von geschlossen auf offen und wieder geschlossen
wechselt. Wird die Drehrichtung geändert vertauschen die Pins ihre
rollen.
Die Drehgeber Pins sind übrigens die drei Pins nahe am Schaft, die
übrigen vier Pins gehören zu dem Druckschalter.
Wie gesagt ich hab im Netzt nichts über den Encoder gefunden, ich hoffe
dies hilft jemand der den gleichen Encoder hat.
Als Anhang ein Arduino Sketch der recht zuverlässig den Drehgeber
ausliest.
Martin
>(http://www.pollin.de/shop/dt/MjA2OTU3OTk-/Baueleme...)>mitbestellt und dann rumliegen lassen weil ich ihn nicht gleich>brauchte. Jetzt hab ich versucht ihn mit einem Arduino auszulesen uns>festgestellt, dass er nicht dem üblichen A/B-Graycode benutzt.
Glaub ich nicht.
>Anscheinend funktioniert er folgendermaßen: beim Drehen in eine Richtung>bleibt ein Pin-Kontakt immer offen, während der andere für jede>Rasterung einmal von geschlossen auf offen und wieder geschlossen>wechselt. Wird die Drehrichtung geändert vertauschen die Pins ihre>rollen.
Nö. Der Encoder macht 2 Schritte pro Rastung.
siehe Drehgeber
Falk B. schrieb:>>(http://www.pollin.de/shop/dt/MjA2OTU3OTk-/Baueleme...)>>mitbestellt und dann rumliegen lassen weil ich ihn nicht gleich>>brauchte. Jetzt hab ich versucht ihn mit einem Arduino auszulesen uns>>festgestellt, dass er nicht dem üblichen A/B-Graycode benutzt.>> Glaub ich nicht.>
Ehrlich gesagt zweifel ich auch noch etwas daran. Vielleicht hab ich die
Pinbelegung falsch geraten?
>>Anscheinend funktioniert er folgendermaßen: beim Drehen in eine Richtung>>bleibt ein Pin-Kontakt immer offen, während der andere für jede>>Rasterung einmal von geschlossen auf offen und wieder geschlossen>>wechselt. Wird die Drehrichtung geändert vertauschen die Pins ihre>>rollen.>> Nö. Der Encoder macht 2 Schritte pro Rastung.>> siehe Drehgeber
Genau den Beispiel-Code (angepasst auf Arduino) aus dem Artikel hab ich
zuerst benutzt, aber leider funktioniert er nicht mit dem Encoder. Er
zeigt jeweils nur bei Richtungsänderungen eine Bewegung um +1/-1 an,
auch wenn ich die verschiedenen encode_read1/2/4 Funktionen benutze.
Auch ein anderes Arduino-Beispiel lief nicht mit dem Encoder. Vielleicht
steh ich aber auch nur total auf dem Schlauch :-(.
Ich hab mir auch einen kleinen Sketch geschrieben, der über Pin-Change
Interrupts die Änderungen der Zustände beim Drehen anzeigt, und bin
darüber auf meine Theorie oben gekommen.
Ich hab auch kein Datenblatt zu dem Encoder gefunden. Wenn jemand den
Encoder identifizieren kann oder vielleicht selbst hat, wäre ich froh
mehr darüber zu erfahren.
Ich hab leider hier kein Logic-Analyzer oder ähnliches, ich will doch
nur spielen ;-)
Martin schrieb:> ... festgestellt, dass er nicht dem üblichen A/B-Graycode benutzt.>> Anscheinend funktioniert er folgendermaßen: beim Drehen in eine Richtung> bleibt ein Pin-Kontakt immer offen, während der andere für jede> Rasterung einmal von geschlossen auf offen und wieder geschlossen> wechselt. Wird die Drehrichtung geändert vertauschen die Pins ihre> rollen.
Das könnte in der Tat mit Pollins Beschreibung ("2 Ausgänge (360°,
links/rechts)") gemeint sein.
Wenn diese Signale in Hardware entprellt sind, dann kann man sie in
Software sehr einfach auswerten.
Aber wenn man die Entprellung in Software machen soll, dann bleibt einem
nur, auf das Timing zu achten. ("Prellst du noch oder schaltest du
schon?")
Heutzutage gibt es fertige Gray-Code-Auswertung in Software und
Hardware; das ist vermutlich der Grund, warum diese Dinger bei Pollin
verramscht wurden.
Also du musst irgendwo einen Fehler gemacht haben.
Mit einem Atmega328 ohne Arduino-Gedöns habe ich die Dinger gut ans
laufen bekommen - prellten zwar wie nichts gutes und haben nicht richtig
gerastet ABER der Code hat funktioniert!
Irgendwo muss bei der das Problem liegen...
@ Martin (Gast)
>Ehrlich gesagt zweifel ich auch noch etwas daran. Vielleicht hab ich die>Pinbelegung falsch geraten?
Kann sein. Wenn man GND mit einem der Phasen verwechselt kommt sowas
raus, ist mir auch schon passiert.
Ok, ihr habt mich überzeugt. Hätte mich auch schon stutzig machen
sollen, das nirgendwo im Netz was über andere Funktionsweisen von
Drehencodern stand.
Danke für alle Hinweise :-).
Das Dumme ist, ich hab den Drehencoder immer noch nicht am laufen. Die
Pins A und B sind ja austauschbar (abgesehen von der Drehrichtung
oder?), dann gibt es doch nur drei Möglichkeiten die Pins zuzuordnen,
nämlich wo man die Masse anschließt oder?
Ich hab alle Möglichkeiten ausprobiert... immer noch nix. Ich mach mich
nochmal auf Fehlersuche.
ChiefEinherjar, es wäre Prima, wenn du mir sagen könntest wie du die
Drehgeber verdrahtet hast. Das wäre eine Unsicherheit weniger.
Naja hat Spaß gemacht etwas zu tüfteln auch wenn nix dabei rausgekommen
ist.
Martin schrieb:> Ich hab alle Möglichkeiten ausprobiert... immer noch nix. Ich mach mich> nochmal auf Fehlersuche.
Ich frage mich zwar, wie diese Diskussion hier mit dem Untertitel des
Forums zu vereinbaren ist ("Hier könnt ihr eure Projekte, Schaltungen
oder Codeschnipsel vorstellen und diskutieren. Bitte hier keine Fragen
posten!"), da es in diesem Zustand wohl kaum als irgendwie
abgeschlossenes Projekt bezeichnet werden kann - aber sei's drum.
Wenn du Unterstützung brauchst/suchst solltest du vielleicht
systematisch vorgehen und nicht wild mit irgendwelchem Code probieren.
Schalte den µC einfach mal aus, nimm einen Durchgangsprüfer sowie Zettel
und (Karo-)Papier. Dann zeichnest du für alle Kombinationen der Pins als
Funktion des Winkels auf, wann welcher Pin mit welchem anderen
Verbindung hat und zeigst das hier. Damit ließe sich dann weiter kommen.
Wolfgang schrieb:> Ich frage mich zwar, wie diese Diskussion hier mit dem Untertitel des> Forums zu vereinbaren ist
Naja, mit dieser Idee hat der TE ja angefangen, aber mittlerweile
ist es wirklich nur noch eine Diskussion um die Ansteuerung dieses
ALPS-Gebers geworden. Ich schieb's daher mal.
Wolfgang schrieb:> Schalte den µC einfach mal aus, nimm einen Durchgangsprüfer sowie Zettel> und (Karo-)Papier. Dann zeichnest du für alle Kombinationen der Pins als> Funktion des Winkels auf, wann welcher Pin mit welchem anderen> Verbindung hat und zeigst das hier. Damit ließe sich dann weiter kommen.
So ähnlich hab ich das ja gemacht und bin dann zu dem Code, den ich hier
als "Codeschnipsel" zum auslesen dieses Encoders gepostet habe,
gekommen.
Aber da die meisten hier das anscheinend für ziemlich unwahrscheinlich
halten, dass ein Drehencoder anders als traditionell funktionert hab ich
überlegt ob ich was falsch gemacht habe.
Übrigens lässt sich der Drehencoder mit dem Code den ich gepostet habe
wirklich ziemlich zuverlässig auslesen. Solange man ihn so dreht, dass
man noch mitzählen kann stimmt das Ergebnis immer, nur wenn ich ihn wild
hin und her drehe und ihn dann wieder an den Ausgangspunkt zurück drehe
kann es sein das ein oder zwei Schritte verlorengangen sind.
Mit dem "normalen" Drehencoder Algorithmus hab ich ihn immer noch nicht
zum laufen gebracht.
Mittlerweile glaube ich wieder eher das doch etwas an diesem Drehencoder
besonders ist.
Ich hab mir noch zwei Drehencoder bestellt, dann kann ich die mal mit
dem hier vergleichen. Es dauert aber wahrscheinlich noch etwas bis ich
die habe.
Vielen Dank für das verschieben, ich denke auch das macht Sinn.
Martin schrieb:> Ich hab mir noch zwei Drehencoder bestellt
Würde ich ja auch machen, und ihn dann mal an den Logikanalysator
klemmen, aber „Artikel nicht mehr lieferbar“. :(
Martin schrieb:> Aber da die meisten hier das anscheinend für ziemlich unwahrscheinlich> halten, dass ein Drehencoder anders als traditionell funktionert hab ich> überlegt ob ich was falsch gemacht habe.
Es ist ja nicht auszuschließen, dass die Messung falsch war. Der
(funktionierende!) Code ist dann aber doch eine Bestätigung deiner
Beobachtungen.
Was du falsch gemacht hast, ist der fehlende Screenshot des
Oszilloskops/Logic-Analyzers. ;-)
> beim Drehen in eine Richtung bleibt ein Pin-Kontakt immer offen,> während der andere für jede Rasterung einmal von geschlossen auf offen> und wieder geschlossen wechselt.
Wenn es einen Ausgang gibt (der auch wirklich ein Ausgang ist), der sich
über mehrere Schritte nicht ändert, dann kann es kein 'normaler'
(Gray-Code-)Encoder sein.
> Ich hab mir noch zwei Drehencoder bestellt
Das wäre dann wahrscheinlich ein anderes Modell.
