Hallo, ich möchte ein Interentradio mit einem Raspberry basteln. Ich habe dazu einen Drehregler von AlPS (EC11), genauere Bezeichnung unbekannt. Wie in Tutorials und Foren gezeit, wird bei Drehgebern an den Einrastpunkten meistens ein "Greycode" ausgegben: 00 01 11 10. Wenn ich an meinen Drehgeber Dioden ranhänge, erkenne ich allerdings, dass jeder Einrastpunkt den Wert 0 ausgibt; zwischen den Einrastpunkten den Wert 1. Kann mir jemand sagen, wie diese Arte des output-Signals bezeichnet wird, bzw. wie es verarbeitet werden kann? Gruß Daniel
Daniel schrieb: > Wenn ich an meinen Drehgeber Dioden ranhänge, Hast du eigentlich JEMALS vorher Beschreibungen zu korrekten Aufwertung von Drehgebern gelesen ? http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 https://www.mikrocontroller.net/articles/Drehgeber
Daniel schrieb: > dass jeder > Einrastpunkt den Wert 0 ausgibt; zwischen den Einrastpunkten den Wert 1. Das ist GreyCode. Hier steht alles drin, einfach mal weiter nach unten blättern http://www.alps.com/prod/info/E/PDF/Switch/Encoder/EC11/EC11.PDF
Hi Daniel, bei machen Drehgebern liegt das Signal nur kurz an, wenn er "einrastet" und nicht dauerhaft. So welche kannst du also nicht mit LEDs debuggen... Viele Grüße, Michael
?!? schrieb: > Sputnik schrieb: >> Das ist GreyCode. > > https://de.m.wikipedia.org/wiki/Grey-Code a oder e, Jacke wie Hose
Daniel schrieb: > Hallo, > > ich möchte ein Interentradio mit einem Raspberry basteln. > > Ich habe dazu einen Drehregler von AlPS (EC11), genauere Bezeichnung > unbekannt. Wie in Tutorials und Foren gezeit, wird bei Drehgebern an den > Einrastpunkten meistens ein "Greycode" ausgegben: 00 01 11 10. Wenn ich > an meinen Drehgeber Dioden ranhänge, erkenne ich allerdings, dass jeder > Einrastpunkt den Wert 0 ausgibt; zwischen den Einrastpunkten den Wert 1. > Kann mir jemand sagen, wie diese Arte des output-Signals bezeichnet > wird, bzw. wie es verarbeitet werden kann? > > Gruß > > Daniel Es gibt verschiedene Arten von Drehgebern. Schau mal da Beitrag "Re: Drehimpulsgeber" Verarbeiten kannst du sie auf unterschiedliche Weise aber beide gleich ;-)
Danke für die Antworten! Allerdings kapier ich immernoch nicht, warum bei mir JEDER Einrastpunkt "0" ausgibt. Nach der output-Skizze des Datenblattes wechselt der Wert. Oder wird auch der Übergang (der Bereich zwischen 2 festen Drehpositionen) als Rasterpunkte bzw. detent-positions bzw. gestrichelte Linie in der Skizze bezeichnet? Gruß Daniel
Daniel schrieb: > Allerdings kapier ich immernoch nicht, warum bei mir JEDER Einrastpunkt > "0" ausgibt. Zeig mal'n Schaltplan(Skizze) wie Du das machst!
Was erwartest du und warum erwartest du es? Der Drehgeber gibt beim Bewegen einen Bi-Phase-Code aus. Wenn er still steht, dann gibt er feste Werte aus. Bei deinem Geber ist es halt 00. Die anderen Wert 01, 11 und 10 kommen sicher auch. Wo liegt das Problem?
Dreh in mal sehr sehr langsam von einer Rastposition in die nächste. Er könnte ja hier mal so viele Schaltpunkte wie Rastpunkte haben. Dann würde er beim Rasten immer das gleiche ausgeben.
Angehängte Dateien:
Hier die Skizze wie ich den Drehgeber-output getestet habe. Ich gehe jetzt einfach mal davon aus dass er sowas wie 00 01 10 11 irgendwie ausgibt und suche ein braucchbares script welches mit ner Taktfrequenz abtastet. Das Script von http://www.bobrathbone.com/raspberrypi/Raspberry%20Rotary%20Encoders.pdf funktioniert auf jeden Fall mal nicht. Danke euch Gruß Daniel
Daniel schrieb: > funktioniert auf jeden Fall mal nicht. Ganz falsch ist die jedenfalls nicht. Es liegt also eher an dir wenn es damit nicht funktioniert, falscher Verdrahtung oder Anwendung. Warum sollte dann der nächste oder zehnte Vorschlag von dir aufmerksamer umgesetzt werden?
Daniel schrieb: > Wie in Tutorials und Foren gezeit, wird bei Drehgebern an den > Einrastpunkten meistens ein "Greycode" ausgegben: 00 01 11 10. und schon falsch. Wo willst du das gelesen haben? Daniel schrieb: > Allerdings kapier ich immernoch nicht, warum bei mir JEDER Einrastpunkt > "0" ausgibt. Weil gängige Drehgeber keineswegs einen Rastpunkt auf jedem Code der Sequenz haben, sondern eher einen Rastpunkt alle 2 Codes (gleich 2 Rastpunkte pro Sequenz) oder gar nur einen Rastpunkt alle 4 Codes (ein Rastpunkt pro Sequenz). Ein Drehgeber der letzten Art würde dann ganz natürlich bei jedem Rastpunkt den gleichen Code ausgeben. Die Zwischencodes natürlich auch, aber die sind so schnell vorbei, daß du sie mit dem bloßen Auge nicht siehst.
Ich verstehe nun. Wenn ich den Drehgeber seeeeehr langsam drehe, funktioniert auch alles. Also muss ich jetzt einen langsameren Drehgeber finden.
Daniel schrieb: > Hier die Skizze wie ich den Drehgeber-output getestet habe. Dann ist "0" bei dir LEDs aus und "1" LED an ? Die meisten der Anderen Leser erwarten vermutlich für "0" eine Verbindung nach GND (LEDs an). So würde es auch ein Controller sehen. Keine Verbindung nach GND -> logisch "1". Dein Drehgeber passt schon. Du musst nur verstehen wie er funktioniert und ihn dementsprechend auswerten.
:
Bearbeitet durch User
Daniel schrieb: > Wenn ich den Drehgeber seeeeehr langsam drehe, > funktioniert auch alles. Also muss ich jetzt einen langsameren Drehgeber > finden. Unsinn, nur dein Programm ausreichend schnell laufen lassen. Mit dem richtigen Programm schafft ein uC locker 1 Mio Striche pro Sekunde, also 250000 Schritte und je nach Drehgeberschrittanzahl 468000upm. Wahrscheinlich wirst du deine RPi auf 10-fache Rechengeschwindigkeit aufrüsten, damit der Phython Skript in Webumgebung schnell genug abgearbeitet wird, argh.
Volker S. schrieb: > Dann ist "0" bei dir LEDs aus und "1" LED an ? Nein, umgekehrt. Der Drehgeber schaltet in der Skizze gegen GND.
npn schrieb: > Volker S. schrieb: >> Dann ist "0" bei dir LEDs aus und "1" LED an ? > > Nein, umgekehrt. Der Drehgeber schaltet in der Skizze gegen GND. Das lassen wir wohl lieber den Daniel beantworten. Ich könnte mir vorstellen für Ihn ist "0" -> Null Licht ;-)
Ich werde mal versuchen die "solide Lösung" von https://www.mikrocontroller.net/articles/Drehgeber in die python-Sprache umzuwandeln
Daniel schrieb: > Ich verstehe nun. Wenn ich den Drehgeber seeeeehr langsam drehe, > funktioniert auch alles. Also muss ich jetzt einen langsameren Drehgeber > finden Nein, bei dem langsam ging es darum, dass du selber die anderen Zustände siehst. Wenn du den schneller drehst werden die Pulse einfach zu kurz um sie zu sehen. Dein Raspberry hat damit keine Probleme.
Angehängte Dateien:
-
drehgeber_state_machine.png
24 KB -
drehgeber_prellen.png
5,5 KB
Habe selber mal eine Auswertung für einen solchen Drehgeber implementiert und auch lange üben müssen. Es ist auch zu beachten, dass gewisse Drehgeber wie Sau prellen. Meine schlussendlich sehr gut funktionierende Lösung bestand darin, die beiden Signale vom Drehgeber periodisch abzutasten (ich glaube ca. alle 1ms) und dann die eingelesenen Zustände einer kleinen State-Machine zuzuführen, welche die Zustandswechsel auswertete (siehe Bild). Im zweiten Bild siehst Du das Prellen, welches bei mir je nach Drehgeschwindigkeit vorkam. Wegen diesem funktioniert die Auswertung per Interrupt überhaupt nicht zuverlässig, daher verzichtete ich dann auf Interrupts von den I/O's. Wie Du schon festgestellt hast, haben die beiden Signale A und B im eingerasteten Zustand immer denselben Zustand, also beide 0 oder beide 1. Die unterschiedlichen Zustände von A und B während der Drehung kommen nur sehr kurz vor und sind mit Deinen LED's mit blossem Auge wohl nicht erkennbar.
:
Bearbeitet durch User
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.