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.
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.