Optischer Rotary-Encoder an Arduino zählt nicht richtig
LTD 07.12.2020 - 19:02 5548 7
LTD
frecher fratz
|
Hello,
hat einer der Coding-Profis hier jemals mit einem Rotary-Encoder (Drehinkrementalgeber) gearbeitet? Ich habe mit meinem Arduino das Problem, dass er mir aus bisher unerklärlichen Gründen ab und an Werte liefert, die völlig daneben sind. Das passiert fast nur, wenn ich in void loop() neben dem Drehencoder noch andere Funktionen packe bzw. diese von dort aus aufrufe...
Als code verwende ich die 0815 Encoder Bibliothek. Ich hab es mit oder ohne Interrupts probiert, machte keinen Unterschied.
Die zweite Funktion dient zum bespielen eines OLED, eventuell fordert das zu viel Leistung vom Arduino?
Vielen Dank für eure Hilfe!
|
Vinci
hatin' on summer
|
Das passiert fast nur, wenn ich in void loop() neben dem Drehencoder noch andere Funktionen packe bzw. diese von dort aus aufrufe... Das deutet darauf hin, dass dein Arduino eine Software-Implementierung zum Auslesen der Drehgeber nutzt. Da wäre mal wichtig zu prüfen wie groß hier die Abtastfrequenz ist. Das absolute Minimum wäre das Doppelte der maximalen Drehfrequenz des Gebers.
|
LTD
frecher fratz
|
Danke, versuche ich gleich mal rauszufinden. Laut den Foren sollte der Arduino bis zu 60000 pro Sekunde schaffen ...
Was mich irritiert ist, dass die werte so "springen". Also von 32 auf 212, dann wieder auf 60, dann springt er auf einer Zahl +-2 herum. Und das passiert fast ausschließlich gegen den Uhrzeigersinn. Zuerst dachte ich, dass eventuell einer der Signalwege defekt ist, aber er zählt tadellos die 4 Schritte.
|
Vinci
hatin' on summer
|
Ein paar Schritte auf und ab kann bei billigen Drehgebern die stark prellen (und schlechtem Arduino-Code) schon mal vorkommen. Es gibt auch so tolle Dinger wo Pegelwechsel an den Ausgängen direkt an den Rastpunkten erfolgen...  Wenn aber 200 Werte übersprungen werden is irgendwas grob falsch.
|
InfiX
she/her
|
debounce solltest bei einem optischen eigentlich eh nicht brauchen.
|
LTD
frecher fratz
|
debounce solltest bei einem optischen eigentlich eh nicht brauchen. Genau, er funktioniert auch wirklich tadellos, wenn er "alleine" läuft. Da kann man drehen wie man will, er ist immer perfekt genau. Hier ein Ausschnitt der Werte mit Zeitstempel. Es beginnt grundsätzlich mit einer langsamen Drehung gegen den Uhrzeigersinn und ab dann ist es vorbei. 21:55:13.809 -> 68 21:55:13.949 -> 66 21:55:14.059 -> 59 21:55:14.166 -> 54 21:55:14.311 -> 48 21:55:14.417 -> 48 21:55:14.529 -> 48 21:55:14.669 -> 47 21:55:14.777 -> 32 21:55:14.882 -> 18 21:55:15.023 -> 124 21:55:15.134 -> 124 21:55:15.280 -> 123 21:55:15.384 -> 119 21:55:15.489 -> 107 Und hier wenn man ihn "alleine" laufen lässt - auch ohne Interrupts absolut kein Problem: 22:17:52.278 -> -10 22:17:52.278 -> -9 22:17:52.316 -> -8 22:17:52.387 -> -7 22:17:52.387 -> -6 22:17:52.420 -> -5 22:17:52.420 -> -4 22:17:52.530 -> -3 22:17:52.530 -> -2 22:17:52.568 -> -1 22:17:52.568 -> 0 22:17:52.606 -> 1 22:17:52.644 -> 2 22:17:52.644 -> 3 22:17:52.644 -> 4 22:17:52.679 -> 5 22:17:52.746 -> 6 22:17:52.746 -> 7 22:17:52.746 -> 8 22:17:52.781 -> 9 22:17:52.781 -> 10
|
LTD
frecher fratz
|
Das gibts ja nicht, ich hab das Problem gefunden: wenn ich statt Pin 6/7 und 7/8 einfach 6/8 nehm (also einen frei lasse), geht es perfekt. Haben die Pins Crosstalk oder wie erklärt man das?
|
NL223
RoHS-konform
|
schon möglich
könnte am Arduinopin liegen - es gibt verschiedene PINs die sich nicht immer gleich verhalten, je nach funktionen der µC die drauf sind können die Pins interne Pull Up/Downs haben oder nicht, können CMOS, Schmitttrigger oder TTL kompatibel sein...
dazu müsste man sich die "alternativfunktionen" der PINS bzw. das genaue Datenblatt vom verwendeten Arduino/dessen µC ansehen und die Ausgänge des Encoders - hat der zB open Collector/Drain Ausgänge wird nur einer der logischen Zustände angelegt, der zweite Zustand ist dann bei fehlendem Pull-Up/Down eventuell undefiniert, bzw. fängt man z.B. 50Hz Brumm vom Lichtnetz ein oder andere Störungen ...
|
Anmeldung