Hallo zusammen,
ich arbeite gerade an einer µC-Steuerung für einen DC-Motor. An diesem
sitzt ein magnetischer Encoder. Dieser hat bereits Logik auf der
Platine, so dass er ein Quadratur-Signal ausgibt. Sicherheitshalber hier
das Datenblatt:
http://www.maxonmotor.com/medias/sys_master/root/8816794173470/15-349-DE.pdf
Zur Auswertung benutze ich etwas abgewandelt diesen Code aus dem Forum:
http://www.mikrocontroller.net/attachment/1971/ENCODE.C
(geändert habe ich lediglich den Datentyp von enc_delta auf int16_t)
Wenn ich mir die Position in der Hauptschleife über den UART an den PC
geben lasse und den Motor langsam in eine Richtung durchdrehe, dann
steigen die Werte über einen längeren Zeitraum gesehen, springen aber
zwischendurch immer wieder ein paar Stufen zurück. Beispiel:
1000
1123
1456
1346
1567
1566
Das angehangene Oszi-Bild zeigt die Abtastung der Phase_A.
Wie kann ich diesen Effekt verhindern? Ich habe bereits versucht die
Encoder-Ausgänge durch zwei 22nF Kondensatoren gegen Masse etwas zu
entstören (auf dem Bild sind sie bereits angeschlossen).
Gruß
Marvin
@ Marvin Noll (marvin_n)
>Wenn ich mir die Position in der Hauptschleife über den UART an den PC>geben lasse und den Motor langsam in eine Richtung durchdrehe, dann>steigen die Werte über einen längeren Zeitraum gesehen, springen aber>zwischendurch immer wieder ein paar Stufen zurück. Beispiel:
Zu geringe Abtastrate?
Welchen Typ von Encoder hast du denn? Im Datenblatt gibt es verschiedene
mit 64-256 Impulsen/U. Pro Zyklus gibt es 4 Codewechsel, die man
sicherheitshalber mit mindestens der doppelten Frequenz abtasten sollte.
Macht also je nach Typ mindestens 512-2048 Abtastungen/U.
>Das angehangene Oszi-Bild zeigt die Abtastung der Phase_A.
Die allein nützt nichts, man muss den Zusammenhang zu B sehen.
>Wie kann ich diesen Effekt verhindern? Ich habe bereits versucht die>Encoder-Ausgänge durch zwei 22nF Kondensatoren gegen Masse etwas zu>entstören (auf dem Bild sind sie bereits angeschlossen).
AUA! NEIN! Sofort wieder entfernen!
m.n. schrieb:> Bei diesen schnellen Signalen mußt Du per Interrupt auswerten.
Was ist das für ein hanebüchener Trollbeitrag? Au weia, Dummheit in
Säcken.
Ja, die Auswertung ist für die 19kHz Signale wohl zu langsam, maximal
20us dürfen zwischen den Auswertungen liegen und der Code ist zu dumm,
um Unterabtastung zu erkennen und als Fehler zu liefern.
Aber wir hatten schon festgestellt, in threads die auch ein m.n. gelesen
hat, daß ein 20MHz AVR per polling durchaus 8 Drehgeber mit 900kHz
simultan abtasten kann, wenn man ordentlich programmieren kann,
schneller als jede Flankenauswertung (Interrupt sagt ja erst mal nichts,
kann ja auch ein Timerinterrupt sein).
Für 1 Drehgeber mit 20ksps reicht auch C per Timerinterrupt.
Falk B. schrieb:> Ich habe bereits versucht die>>Encoder-Ausgänge durch zwei 22nF Kondensatoren gegen Masse etwas zu>>entstören (auf dem Bild sind sie bereits angeschlossen).>> AUA! NEIN! Sofort wieder entfernen!
Ich habe mir die Idee von diesem Panasonic-Drehgeber abgeschaut:
http://www.pollin.de/shop/downloads/D240313D.PDF
Ohne diese Kondensatoren waren auf dem Quadratursignal viele Spikes zu
sehen. Könnte vielleicht auch ein Effekt des Oszilloskopes sein.
Ich werde mal die Kondensatoren entfernen und die Abtastrate erhöhen.
Zur Auswertung mittels Interrupts: Im Wiki-Artikel zu Drehgeber ist
beschrieben, dass die Variante "Interrupt bei Phase-A, dann Phase-B
prüfen" eher nicht zu empfehlen ist. Gilt dies nur für Drehgeber mit
Rastpunkten?
@ marvin_n (Gast)
>Ich habe mir die Idee von diesem Panasonic-Drehgeber abgeschaut:>http://www.pollin.de/shop/downloads/D240313D.PDF
Bitte mal GENAU hinsehen! Da sind nicht einfach 100nF am IO-Pin, sondern
auch noch 10k in Reihe! Das ist ein Unterschied! Dieses RC-Glied ist ein
Tiefpass gegen SEHR hochfrequente Störungen. Er dard aber bei maximaler
Drehzahl nicht zum Verschlucken von Pulsen führen!
>Zur Auswertung mittels Interrupts: Im Wiki-Artikel zu Drehgeber ist>beschrieben, dass die Variante "Interrupt bei Phase-A, dann Phase-B>prüfen" eher nicht zu empfehlen ist. Gilt dies nur für Drehgeber mit>Rastpunkten?
Das gilt allgemein, auch wenn einige Leute das in religiösem Eifer
anzweifeln.
MaWin schrieb:> Was ist das für ein hanebüchener Trollbeitrag? Au weia, Dummheit in> Säcken.
Du sagst es. Willst Du aus dem Sack wieder raus?
marvin_n schrieb:> Ich habe mir die Idee von diesem Panasonic-Drehgeber abgeschaut:> http://www.pollin.de/shop/downloads/D240313D.PDF
Der ist ja ganz nett, aber das verlinkte Datenblatt spricht von bis zu
320 kHz.
@ m.n. (Gast)
>Der ist ja ganz nett, aber das verlinkte Datenblatt spricht von bis zu>320 kHz.
There aint no such thing as free lunch.
Wenn ich einen hochauflösenden Encoder mit hohen Drehzahlen betreibe,
muss ich mit den Folgen leben.
Falk B. schrieb:> There aint no such thing as free lunch.>> Wenn ich einen hochauflösenden Encoder mit hohen Drehzahlen betreibe,> muss ich mit den Folgen leben.
Ja, dann kann es passieren, daß das Lunch aus der Pfanne geschleudert
wird, wenn das Spiegelei nicht exakt zentriert war.
:-)
SCNR Paul
Marvin N. schrieb:> Wie kann ich diesen Effekt verhindern?
Bei Drehgebern, die flotte Signale im höheren kHz Bereich liefern und
die (wie du schriebest) bereits die Signale formatiert und damit
glitchfrei liefern, ist es ratsam, sich den zu verwendenden µC danach
auszusuchen. Guck bei NXP mal nach, die haben Cortexe im Portfolio,
welche dafür einen Hardware-Peripheriecore enthalten. Den benutzt du
dann, kriegst zu jeder Zeit den Stand des Postitionszählers und wohl
auch direkt einen Wert für die aktuelle Geschwindigkeit.
Wenn die Wahl des µC dir keine Option ist, und wenn der µC schnell genug
ist, dann mußt du eben mit Interrupts arbeiten. Ist manchmal auch kein
Problem, denn gewöhnliche Motoren laufen ja zumeist unter 6000 rpm und
das multipliziert mit der Encoderrate (in Zyklen/Umdrehung) ergibt die
Interruptrate - die dein µC natürlich abkönnen muß.
Optische "Drehgeber" auf der Motorachse sind ein ganz anderes Thema als
der mechanische Pollinsche Drehknopf von Panasonic. Das hat unser MaWin
mal wieder durcheinander gebracht mit seiner fixen Idee vom Polling. Und
erfrischend ist auch sein Konverationsstil: "Was ist das für ein
hanebüchener Trollbeitrag? Au weia, Dummheit in Säcken."
W.S.
Marvin N. schrieb:> Wie kann ich diesen Effekt verhindern?
Falls du dir nicht selber ein Board designen willst, könntest du einen
Arduino nehmen, der Encoderauswertung per Hardware unterstützt.
Das Board ist (leider) schon fertig. Ich verwende als Motorcontroller
einen L6202 und als µC einen ATMEGA16.
Als Gesamtziel soll eine (absolute) Positionierung des DC-Motors mit
einer Inkrementzahl als Sollwert erfolgen. Ich habe mir erhofft eine
PID-Regelung in Software zu realisieren. Für die praktische Anwendung
muss der Motor nur ein paar Grad vor und zurück verdreht werden können.
Gibt es ICs, welche das Encoder einlesen gut können und würde mir das
etwas helfen?
@ marvin_n (Gast)
>Das Board ist (leider) schon fertig. Ich verwende als Motorcontroller>einen L6202
Das ist nur ein Treiber, kein Controller.
> und als µC einen ATMEGA16.>Als Gesamtziel soll eine (absolute) Positionierung des DC-Motors mit>einer Inkrementzahl als Sollwert erfolgen.
Also ein Servo.
> Ich habe mir erhofft eine>PID-Regelung in Software zu realisieren. Für die praktische Anwendung>muss der Motor nur ein paar Grad vor und zurück verdreht werden können.
Wie schnell?
>Gibt es ICs, welche das Encoder einlesen gut können und würde mir das>etwas helfen?
Mal nicht so schnell.
1.) Welchen Encoder hast du GENAU?
2.) Wieviele Pulse macht der pro Umdrehung?
3.) Mit welcher Frequenz tastest du den Encoder ab?
Auch mit deinem AVR kann man problemlos mit 20-50 kHz in Software
abtasten. Der Meister aus Fernost macht es wie immer vor.
http://elm-chan.org/works/smc/report_e.html
Also, ich habe jetzt mal ein paar Details:
-der Encoder erzeugt nach Typenbezeichnung 256 Impulse pro Umdrehung. Da
noch ein Getriebe verwendet wird, entstehen bei jeder Umdrehung etwa
12000 Impulse.
-Angehängt habe ich nochmal zwei Oszi-Bilder. Beide zeigen die
Abtastung(pink) und die A/B-Kanäle des Encoders. Bei 00008 sind die 22nF
Kondensatoren noch angeschlossen, bei 00009 nicht mehr (Die Einbrüche in
der Mitte der Pulse sehen problematisch aus).
Laut den Oszilloskop-Messungen wird etwa 4 mal pro Puls abgetastet, wenn
ich das richtig interpretiere.
In diesen Fall ist min. 2* abtasten /pulse eigentlich zu wenig : Bei 2
Kanalen um 90° versetzt soll men minimal 4*/puls auswerten, um 100%
sicher die richtige Folge von A/B zu erfassen. Haben sie das gleiche
Problem wen der Motor sich langsam dreht ? Die kleine Rimpel auf das
Signal scheint mir problemlos. Wie sieht aus mit die Spannungspegel ?
(ich siehe da 500 mV/division stehen, sieht aus das die Spannungen nur
500 mV sein).
Marvin N. schrieb:> (Die Einbrüche in der Mitte der Pulse sehen problematisch aus).
Das sieht mir nach einem "wer Mist misst, misst Mist"-Effekt aus. Wie
ist das Messgerät angeschlossen? Wie ist die Masse angeschlossen? Wo
sind die Kondensatoren angeschlossen? Wie sieht der gesamte Aufbau aus?
Wie weit weg ist der Geber?
Obacht: diese Fragen beziehen sich allesamt auf die räumliche
Anordnung der Kondesatoren und des Messaufbaus...
> Laut den Oszilloskop-Messungen wird etwa 4 mal pro Puls abgetastet
Was ist das lila Signal?
> bei jeder Umdrehung etwa 12000 Impulse.
Und wie oft umdreht der sich pro Sekunde?
Hast du in dem von dir verlinkten Datenblatt gesehen, dass man da einen
differentiellen Eingangstreiber nehmen könnte? Und das auch empfohlen
wird...
marvin_n schrieb:> Gibt es ICs, welche das Encoder einlesen gut können und würde mir das> etwas helfen?
Ein 8-pol. ATtiny25. Dazu habe ich Dir doch oben einen Link gegeben. Der
würde mit seinem IIC-Bus an die jetzigen Eingänge PC.0 und PC.1 passen.
Alternativ kannst Du einen neueren Ersatztypen für den ..16 nehmen. Ein
ATmega164 kann an (fast) allen Eingängen PCINTs auslösen lassen. Damit
kannst Du die Erfassung mit der vorhandenen Schaltung per Interrupt
programmieren.
Wo ist das Problem?
m.n. schrieb:> marvin_n schrieb:>> Gibt es ICs, welche das Encoder einlesen gut können und würde mir das>> etwas helfen?>> Ein 8-pol. ATtiny25. Dazu habe ich Dir doch oben einen Link gegeben. Der> würde mit seinem IIC-Bus an die jetzigen Eingänge PC.0 und PC.1 passen.>> Alternativ kannst Du einen neueren Ersatztypen für den ..16 nehmen. Ein> ATmega164 kann an (fast) allen Eingängen PCINTs auslösen lassen. Damit> kannst Du die Erfassung mit der vorhandenen Schaltung per Interrupt> programmieren.
Werde ich mir ansehen, aber wahrscheinlich werde ich zunächst beim
MEGA16 bleiben.
zu lkmiller:
Bei dem lila Signal stellt jede Flanke eine Abtastung dar, denn ich
lasse den OC0 Pin toggeln.
Der Motor dreht etwa 1/3 Umdrehung pro Sekunde, wenn er an VCC gelegt
wird. Da ich aber den Motor auf eine bestimmte Position fahren möchte,
werde ich hier ohnehin mit PWM arbeiten müssen.
Zum Datenblatt:
Dies war nur zur allgemeinen Info gedacht. Mein konkreter Encoder hat
lediglich die Ausgänge A und B (also nur nicht-invertiert).
Zur Messung:
Das Oszilloskop ist direkt an den AVR-Pins angeschlossen. Die Masse am
Gehäuse des 7805. Der Motor und der Encoder sind über ein geschirmtes 3
m langes Kabel angeschlossen. Direkt am Encoder habe ich die
Spannungsversorgung für den Encoder mit einem 22nF und einem 1µF
Kondensator gepuffert.
In meinem Versuch mit den zwei 22nF Kondensatoren an den A/B-Ausgängen
waren diese in der Nähe des AVR angeschlossen.
Ich habe die Abtastung jetzt auf etwa 8 Abtastungen pro Puls erhöht. Es
scheint so, als würde der Encoder nun maximal +-1 in die Gegenrichtung
zählen, was wohl auf mechanisches Spiel zurückzuführen ist.
Nun muss aus dem Ganzen "nur" noch ein Servo werden.
probiere doch mal dieses Beispiel für 2-fach Auswertung:
volatile int32_t count;
#define PHASE_A 0 // PC.0
#define PHASE_B 1 // PC.1
#define MASKE ((1<<PHASE_A) + (1<<PHASE_B))
ISR(PCINT2_vect)
{
int8_t temp;
temp = PINC; // nur ein einziger Zugriff auf PINC !
if((temp & MASKE) == MASKE || (temp & MASKE) == 0)
temp = 1;
else
temp = -1;
count += temp; // verkürzt den Code
}
Zuvor muß noch der PinChange-Interrupt von PC.0 freigegeben werden:
PCMSK2 = 1; // nur PCINT16
PCICR |= 1<<PCIE2;
Supersimpel.
Marvin N. schrieb:> Werde ich mir ansehen, aber wahrscheinlich werde ich zunächst beim> MEGA16 bleiben.
Wie Du meinst; dann vergiß den gezeigten Code.
Lothar M. schrieb:>> (Die Einbrüche in der Mitte der Pulse sehen problematisch aus).> Das sieht mir nach einem "wer Mist misst, misst Mist"-Effekt aus
Das sind die Umschaltmomente des jeweils anderen Kanals, über die 22nF
Kondensatoren erst in Masse, dann das Signal eingekoppelt, aber zu klein
um zu stören.
Marvin N. schrieb:> Nun muss aus dem Ganzen "nur" noch ein Servo werden.http://www.uhu-servo.de/servo_de/
Richtig ausgewertet mit über 100000 Schritten pro Sekunde ohne
Schrittfehler.
m.n. schrieb:> Wie Du meinst; dann vergiß den gezeigten Code.
Wohl wahr, den Flankengesteuerten Scheiss besser vergessen, der kommt
mit Flattereffekten gar nicht zurecht.
@ Marvin Noll (marvin_n)
>-der Encoder erzeugt nach Typenbezeichnung 256 Impulse pro Umdrehung. Da>noch ein Getriebe verwendet wird, entstehen bei jeder Umdrehung etwa>12000 Impulse.
Bezogen auf den Getriebeausgang. Ganz schön viel.
>-Angehängt habe ich nochmal zwei Oszi-Bilder. Beide zeigen die>Abtastung(pink)
Was soll das sein? Das sind ~ 150 kHz. Wer erzeugt dieses Signal zur
Abtastung?
>und die A/B-Kanäle des Encoders. Bei 00008 sind die 22nF>Kondensatoren noch angeschlossen, bei 00009 nicht mehr (Die Einbrüche in>der Mitte der Pulse sehen problematisch aus).
Sieht nach Messfehlern oder Störungen durch ungünstige
Leitungsführung/Masse aus.
>Laut den Oszilloskop-Messungen wird etwa 4 mal pro Puls abgetastet, wenn>ich das richtig interpretiere.
Das ist zu wenig, zu knapp.
Die Pegel sind mit 500mV arg klein. Kann es sein, dass du vergessen
hast, den 10:1 Tastkopf im Oszi einzustellen? Denn dann wären es 5V, das
wäre wieder OK.
@ Marvin Noll (marvin_n)
>Werde ich mir ansehen, aber wahrscheinlich werde ich zunächst beim>MEGA16 bleiben.
Das ist OK.
>Bei dem lila Signal stellt jede Flanke eine Abtastung dar, denn ich>lasse den OC0 Pin toggeln.
???
Willst du uns erzählen, dass du mit ~300 kHz eine ISR zur Abtastung
betreibst? Niemals, das schafft der AVR in C nicht, auch nicht bei 20
MHz.
Dein Oszi zeigt 10us Zeitbasis an. Oder hast du irgendwie gezoomt?
>Der Motor dreht etwa 1/3 Umdrehung pro Sekunde, wenn er an VCC gelegt>wird.
Am AUSgang vom Getrieb. Macht laut deinen Angaben ~4000 Pulse/s, die mit
min. 32 kHz abgetastet werden müssen.
> Da ich aber den Motor auf eine bestimmte Position fahren möchte,>werde ich hier ohnehin mit PWM arbeiten müssen.
Sicher.
>Das Oszilloskop ist direkt an den AVR-Pins angeschlossen. Die Masse am>Gehäuse des 7805. Der Motor und der Encoder sind über ein geschirmtes 3>m langes Kabel angeschlossen.
Da kann einiges in die Encodersignale einkoppeln.
>Ich habe die Abtastung jetzt auf etwa 8 Abtastungen pro Puls erhöht. Es>scheint so, als würde der Encoder nun maximal +-1 in die Gegenrichtung>zählen, was wohl auf mechanisches Spiel zurückzuführen ist.
Ja.
Wie bereits gesagt habe ich die Abtastung auf 8 pro Puls erhöht.
>Die Pegel sind mit 500mV arg klein. Kann es sein, dass du vergessen>hast, den 10:1 Tastkopf im Oszi einzustellen? Denn dann wären es 5V, das>wäre wieder OK.
Die Pegel sind 5V. Ich verwende einen 10x Tastkopf.
>>-Angehängt habe ich nochmal zwei Oszi-Bilder. Beide zeigen die>>Abtastung(pink)>>Was soll das sein? Das sind ~ 150 kHz. Wer erzeugt dieses Signal zur>Abtastung?
Bei dem lila Signal stellt jede Flanke eine Abtastung dar, denn ich
lasse den OC0 Pin toggeln. Es wird der Timer0 im CTC-Modus verwendet.
>http://www.uhu-servo.de/servo_de/>Richtig ausgewertet mit über 100000 Schritten pro Sekunde ohne>Schrittfehler.
Den kann ich aber nur fertig kaufen wie es aussieht. Ein Projektbeispiel
mit etwas Code wäre da nützlicher.
@ Marvin Noll (marvin_n)
>Die Pegel sind 5V. Ich verwende einen 10x Tastkopf.
Dann stell das am Oszi ein!
>Bei dem lila Signal stellt jede Flanke eine Abtastung dar, denn ich>lasse den OC0 Pin toggeln. Es wird der Timer0 im CTC-Modus verwendet.
Ja und? Dann müsste bei jeder Flanke alle 3us ein Interrupt mit der
Encoderauswertung ausgeführt werden. Das wird er sicher nicht! Das
togglende OC0 Signal macht die Hardware allein, das ist keine Kunst. Ich
vermute mal, dass du massiv Interrupts verlierst und nicht mal
ansatzweise so schnell abtastetst wie du glaubst.
Beweis: Lass das Pin NICHT per Hardware toggeln (COMxx Bits auf 0
setzen) sondern per Software in deiner ISR PORTD ^= (1<<PXY); dann
siehst du wie schnell deine Abtastung WIRKLICH ist!
>Den kann ich aber nur fertig kaufen wie es aussieht. Ein Projektbeispiel>mit etwas Code wäre da nützlicher.
Hast du meinen Link nicht gesehen?
Beitrag "Re: Drehgeber-Auswertung zählt falsch/ungenau"
Falk B. schrieb:>>Bei dem lila Signal stellt jede Flanke eine Abtastung dar, denn ich>>lasse den OC0 Pin toggeln. Es wird der Timer0 im CTC-Modus verwendet.>> Ja und? Dann müsste bei jeder Flanke alle 3us ein Interrupt mit der> Encoderauswertung ausgeführt werden. Das wird er sicher nicht! Das> togglende OC0 Signal macht die Hardware allein, das ist keine Kunst. Ich> vermute mal, dass du massiv Interrupts verlierst und nicht mal> ansatzweise so schnell abtastetst wie du glaubst.>> Beweis: Lass das Pin NICHT per Hardware toggeln (COMxx Bits auf 0> setzen) sondern per Software in deiner ISR PORTD ^= (1<<PXY); dann> siehst du wie schnell deine Abtastung WIRKLICH ist!
Das habe ich gerade mal ausprobiert. Tatsächlich. Es entstehen pro
Encoder Puls nur noch etwa 3 Aufrufe der ISR.
Was könnte ich hier optimieren? (Mal abgesehen von einem anderen µC)
Was passiert, wenn mehr Interrupts erzeugt werden, als verarbeitet
werden? Könnte eine Erhöhung des Prozessortaktes eine Lösung sein? (Ich
benutze momentan schon einen Quarz mit 14MHz)
Ansonsten muss die ISR schneller abgearbeitet werden, aber ich sehe
nicht viel Einsparpotential. Vielleicht beschäftigt auch meine
UART-Kommunikation in der Hauptschleife den µC zu sehr. Dazu benutzte
ich die Peter Fleury uart.c
(http://homepage.hispeed.ch/peterfleury/avr-software.html)
Im Anhang der c-Code bis jetzt.
@ Marvin Noll (marvin_n)
>Das habe ich gerade mal ausprobiert. Tatsächlich. Es entstehen pro>Encoder Puls nur noch etwa 3 Aufrufe der ISR.
Aha.
>Was könnte ich hier optimieren? (Mal abgesehen von einem anderen µC)>Was passiert, wenn mehr Interrupts erzeugt werden, als verarbeitet>werden?
Sie gehen verloren.
> Könnte eine Erhöhung des Prozessortaktes eine Lösung sein? (Ich>benutze momentan schon einen Quarz mit 14MHz)
Sicher, aber fas bringt nur Faktor 20/14 ~ 1,5
>Ansonsten muss die ISR schneller abgearbeitet werden, aber ich sehe>nicht viel Einsparpotential.
enc_delta muss nicht 32 Bit sein, 16 Bit reichen! GGf. sogar 8 Bit. Man
muss halt nur oft genug encoder_read() aufrufen. Oh, das machst du ja
gar nicht, du nutzt nur encdelte. Nicht so gut.
mach enc_delta 8 Bit und rufe in jedem Durchlauf der Hauptschleife
encoder_read() auf. Durch die 8 Bit wird die ISR um einiges kürzer und
schneller.
> Vielleicht beschäftigt auch meine>UART-Kommunikation in der Hauptschleife den µC zu sehr.
Nö. Ausserdem wird die Hauptschleife durch den Interrupt unterbrochen.
>Im Anhang der c-Code bis jetzt.
Naja, ein sehr einfacher Einpunktregler ;-)
Letztendlich muss man aber sagen, dass dein Encoder zuviele Pulse macht
bzw. dein Motor zu schnell dreht. Abhilfe kann hier nur ein Absenken der
Motorspannung bringen, das geht auch mit PWM. Oder ein Wechsel des
Encoders auf weniger Pulse/U. Oder ein uC mit Hardwaredecoder wie z.B.
ein ATXmega, der ist deinem AVR sehr ähnlich.
Falk B. schrieb:> enc_delta muss nicht 32 Bit sein, 16 Bit reichen! GGf. sogar 8 Bit. Man> muss halt nur oft genug encoder_read() aufrufen. Oh, das machst du ja> gar nicht, du nutzt nur encdelte. Nicht so gut.>> mach enc_delta 8 Bit und rufe in jedem Durchlauf der Hauptschleife> encoder_read() auf. Durch die 8 Bit wird die ISR um einiges kürzer und> schneller.
Ich habe in meinem Programm keine Methode encoder_read(). Was soll diese
denn (sinngemäß) machen? Ich muss den enc_delta Wert abholen, bevor
dieser größer/kleiner wird als int16_MAX/int16_MIN.
Speichere ich diesen dann einfach in einer int32 Variable?
Hallo Marvin Noll,
encoder_read() bezieht sich auf eine Encoder-Implementierung von Peter
Dannegger (peda).
Den Code kannst hier im Forum finden oder auch hier mal nachsehen:
https://www.mikrocontroller.net/articles/Drehgeber
@ Marvin Noll (marvin_n)
>Ich habe in meinem Programm keine Methode encoder_read().
Im Original gibt es die aber.
https://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C> Was soll diese>denn (sinngemäß) machen?> Ich muss den enc_delta Wert abholen, bevor>dieser größer/kleiner wird als int16_MAX/int16_MIN.>Speichere ich diesen dann einfach in einer int32 Variable?
JA!
Siehe Beispiel!
Hallo
Ich habe aktuell gerade ein ähnliches Problem, und mich würde es mal
wunder nehmen, weshalb hier immer alle gegen die Pin change interrupts
sind?
Wenn mans richtig macht, dann sprechen weder Prellen noch pendeln
dagegen (abwechslungsweise auf eine Flanke von A oder B warten, den
jeweils ausgeführten Interrupt deaktivieren und und auf den anderen
warten).
Aber leider hab auch ich Probleme, dass Inkrements verloren gehen
Hier mal mein Vorschlag, die beiden ISR reagieren jeweils auf steigende
UND fallende flanken. Ich hab leider auf die Schnelle noch nicht
rausgefunden, wie ich die Interrupts deaktivieren kann auf dem Rpi mit
wiringPi, deshalb die if mit enableInterrupt (hab erst nachher gemerkt
dass es zwar von vorteil sein könnte es so zu machen, wobei auch 2
separate setEncoderPositon() funktionen möglich wären).
1
voidencoderISR_A(void){
2
if(enableInterrupt==1){//for disabling interrupt after 1 execution (to avoid jitter)
3
setEncoderPosition();
4
enableInterrupt=0;
5
}
6
}
7
8
voidencoderISR_B(void){
9
if(enableInterrupt==0){//for disabling interrupt after 1 execution (to avoid jitter)
10
setEncoderPosition();
11
enableInterrupt=1;
12
}
13
}
14
15
voidsetEncoderPosition(void){
16
17
if(enableInterrupt){//interrupt A
18
B=digitalRead(ENCODER_B);
19
if(B){
20
if(A){
21
motorPosition--;
22
}else{
23
motorPosition++;
24
}
25
}
26
else{
27
if(A){
28
motorPosition++;
29
}else{
30
motorPosition--;
31
}
32
}
33
}
34
else{// interrupt B
35
A=digitalRead(ENCODER_A);
36
if(A){
37
if(B){
38
motorPosition++;
39
}
40
else{
41
motorPosition--;
42
}
43
}
44
else{
45
if(B){
46
motorPosition--;
47
}
48
else{
49
motorPosition++;
50
}
51
}
52
}
53
}
-> Aufgrund der abwechselnden Interrupts ist das Signal entprellt, weil
nur die erste von möglicherweise vielen Flanken angeschaut wird.
Patrick B. schrieb:> Ich habe aktuell gerade ein ähnliches Problem, und mich würde es mal> wunder nehmen, weshalb hier immer alle gegen die Pin change interrupts> sind?
Weil das nur Probleme macht, siehe dich selbst.
Patrick B. schrieb:> Wenn mans richtig macht, dann sprechen weder Prellen noch pendeln> dagegen
Doch, du hast nur noch nicht verstanden, wann genau.
Patrick B. schrieb:> Aber leider hab auch ich Probleme, dass Inkrements verloren gehen
Es ist halt die Borniertheit, trotz falschem Ansatz den eigenen Fehler
nicht sehen zu wollen.
Könntet ihr bitte jeweils den Code erst lesen/verstehen, bevor ihr jedes
mal dieselben sinnlosen antworten gebt?
MaWin schrieb:> Patrick B. schrieb:>> Wenn mans richtig macht, dann sprechen weder Prellen noch pendeln>> dagegen>> Doch, du hast nur noch nicht verstanden, wann genau.
Du hast noch nicht ganz verstanden wie der Grey Code funktioniert. alles
weitere ist in meinem vorhergehenden Beitrag beschrieben, bzw. im Code.
Bitte erst durchlesen.
Patrick B. schrieb:> weder Prellen noch pendeln
Was ist denn jetzt Pendeln? Macht es dabei immer tick-tack?
Da zeige ich fertige Lösungen, die weder prellen noch pendeln noch
flattern, aber offensichtlich raffen es die Fragesteller nicht.
Schade.
Patrick B. schrieb:> Du hast noch nicht ganz verstanden wie der Grey Code funktioniert.
Für Quadraturdekoder braucht man keinen Gray-Code zu kennen. Damit
wollen sich gewisse Herrschaften nur aufpusten. Keine Sau addiert
Logarithmen, um damit Multiplikationen auszuführen.
Hi,
jetzt geht mir diese Schlaubergerei langsam auf den S..
m.n. (Gast) schrieb:
>Was ist denn jetzt Pendeln?
zeigt ganz deutlich das du vom Tuten und Blasen keine Ahnung hast.
Auch "MaWin (Gast)" kann immer noch nicht zwischen Eingabegerät und
Messsystem unterscheiden. "Schlaue"/beleidigende Sprüche gehen aber
immer.
Auch ich benutze für Messsysteme 4-fach Auswertung mit PCI und das geht
wie Sau ohne Verlust von Impulsen. Dabei werden Geber vom Typ
ROD486/1024
benutzt die mit bis zu 1200U/min laufen. Das Messen ist aber nur ein
Teil der Aufgabe. Aber das wird den Oberschlaubis vermutlich wenig sagen
denn sie Pollen ja.
Viel Erfolg, Uwe
Uwe schrieb:>>Was ist denn jetzt Pendeln?> zeigt ganz deutlich das du vom Tuten und Blasen keine Ahnung hast.
Stimmt, ich habe andere Neigungen wie zum Beispiel Rechtschreibung und
Interpunktion.
Und was ist jetzt Pendeln?
Das Problem mit dem Code, der auf den Interrupt flanken basiert ist,
nicht ein schnell laufender Encoder, sondern einer der genau im
ungünstigen Zeitpunkt umkehrt und so ggf. auch sehr kurze Pulse erzeugt.
Es geht dann ggf. einer der Pin-Change Interrupts verloren. Bei der SW
oben kommt noch das Problem dazu, wie die Richtung der Flanke erkannt
wird - das kann bei kurzen Pulsen den Fehler noch vergrößern, weil ggf.
eine Falsche Richtung erkannt wird.
Damit der Code oben (und ähnliche varianten) zuverlässig funktioniert
muss die hardware etwa durch tiefpass und Schhmidt Trigger dafür sorgen
das keine zu kurzen Pulse Auftreten können. Das kann ggf. schon über
einen langsamen optischen Detektor und die Hysterese am AVR gegeben
sein.
Man kann die Auswertung auch im Pin Change interupt machen: das Signal
genau einmal abtastet und die Art der Änderung darüber bestimmt, und
nicht ausnutzen dass ein Interrupt ausgelöst wurde und ggf. über welche
Flanke.
m.n. schrieb:> Und was ist jetzt Pendeln?
Scheint dir ja recht schwer zu fallen, darüber nachzudenken, was das
sein könnte. Kleiner Tip: Ein an einem Band aufgehängter Drehgeber, der
hin und her schwingt, ist damit nicht gemeint.
mfg.
Marvin N. schrieb:> bei 00009 nicht mehr (Die Einbrüche in> der Mitte der Pulse sehen problematisch aus).
Die Einbrüche deuten darauf hin, dass beim Encoder ein grundlegendes
Problem mit der Versorgungsspannung oder mit Übersprechen zwischen den
Kanälen besteht. Rumdoktorn mit irgendwelchen Kondensatoren an den
Ausgängen ist da die allerletzte Methode. Da sollte man das Übel an der
Wurzel packen, i.e. Abblockung der Versorgungsspannung prüfen,
Abschlusswiderstände an den Leitungen benutzen, gucken wo sonst das
Übersprechen her kommt.
Thomas E. schrieb:> Kleiner Tip: Ein an einem Band aufgehängter Drehgeber, der> hin und her schwingt, ist damit nicht gemeint.
Ich liebe diese schwachsinnigen Hinweise.
Da steht auf einem Schild: "Hier kein Eingang", anstatt zu schreiben, wo
er denn ist.
Lurchi schrieb:> sondern einer der genau im> ungünstigen Zeitpunkt umkehrt und so ggf. auch sehr kurze Pulse erzeugt.
Dazu möchte ich gerne ein Oszillogramm sehen ;-)
Vielleicht erschließt sich mir ja dann die Definition von "ungünstiger
Zeitpunkt" oder "sehr kurzer Puls".
Drehgeber mit optischen Sensoren oder Hallsensoren habe immer eine
Hysterese, es sei denn der Hersteller will Streß mit der Kundschaft
haben.
Plausibel erscheint mir dann doch das "esoterische Pendeln". Da muß man
nichts zeigen oder gar beweisen und hat trotzdem einen Vorwand, andere
Lösungen niederzutrampeln. Die handelnden Personen dazu sind ja bekannt
;-)
m.n. schrieb:> Ich liebe diese schwachsinnigen Hinweise.
Das freut mich.
m.n. schrieb:> Was ist denn jetzt Pendeln? Macht es dabei immer tick-tack?
Die Fragestellung impliziert, dass du den Begriff für Schwachsinn hältst
und bezweckst, denjenigen, der diesen Begriff genannt hat, in
Erklärungsnot zu bringen.
Was du ja auch hiermit nochmals zum Ausdruck bringst:
m.n. schrieb:> Plausibel erscheint mir dann doch das "esoterische Pendeln". Da muß man> nichts zeigen oder gar beweisen und hat trotzdem einen Vorwand, andere> Lösungen niederzutrampeln. Die handelnden Personen dazu sind ja bekannt
Also, warum soll dir das einer erklären? Finde es doch selber raus.
mfg.
Thomas E. schrieb:> in> Erklärungsnot zu bringen.
Aha! Es liegt also ein Erklärungsnotstand vor, weil das Vorgetragene
offensichtlich nicht zu begründen ist.
Wenn ich an den 'Hl. Geist' glauben soll, mußt Du ihn mir schon zeigen.
Anderfalls sind das nur nachgeplapperte Gerüchte, gegen die man mangels
Überprüfbarkeit nicht argumentieren kann.
Uwe schrieb:> Auch ich benutze für Messsysteme 4-fach Auswertung mit PCI und das geht> wie Sau ohne Verlust von Impulsen.
Es geht doch, wie man sieht!
m.n. schrieb:> Aha! Es liegt also ein Erklärungsnotstand vor, weil das Vorgetragene> offensichtlich nicht zu begründen ist.> Wenn ich an den 'Hl. Geist' glauben soll, mußt Du ihn mir schon zeigen.> Anderfalls sind das nur nachgeplapperte Gerüchte, gegen die man mangels> Überprüfbarkeit nicht argumentieren kann.
Ja nee, is klar.
mfg.
m.n. schrieb:> m.n. schrieb:> 4-fach Auswertung mit PCI>> Das ist dann wohl die schlaue 4-fach Auswertung per flankengetriggertem> Interrupt. So mach ich es auch.
Dass DU das flankengetriggert versuchst, hast du oft genug dargelegt.
Uwe verweist aber auf den Artikel von Peter Dannegger in dem DEUTLICH
darauf hingewiesen wird, dass flankengetriggerze Auswertung nur Probleme
macht, wo die Worte Prellen und Pendeln erklärt werden, und eine solide
Lösung vorgestellt wird, und den DU natürlich bis heute nicht gelesen
hast.
So bleibt man dumm und erzeugt bloss peinliche Auftritte hier.
MaWin schrieb:> Uwe verweist aber auf ....Uwe schrieb:> Auch "MaWin (Gast)" kann immer noch nicht zwischen Eingabegerät und> Messsystem unterscheiden. "Schlaue"/beleidigende Sprüche gehen aber> immer.
Woran du lediglich erkennen kannst, dass ich Leuten fälschliche
persönliche Anmache durchgehen lasse, wenn sie wenigstens fachlich
Richtiges verlinken.
MaWin schrieb:> den DU natürlich bis heute nicht gelesen> hast.>> So bleibt man dumm und erzeugt bloss peinliche Auftritte hier.
Die Behauptung, dass jeder dumm ist, der nicht ständig Peter Danneger
liest, ist natürlich völlig absurd. Ein echter MaWin eben, absolut frei
von jeder sachlichen Grundlage und mit dem Horizont einer
Kaffee-Untertasse. Es gibt durchaus funktionierende Quadratur-Decoder
aufgrund eigenständiger Entwicklungen - nicht nur das, es gibt sogar ICs
dafür. Ich glaube nicht, das Texas Instruments die von PD lizensiert
hat.
Wobei ich gegen Peter überhaupt nichts einzuwenden habe, es ist ja
freundlich, wenn er Software zur Verfügung stellt, aber das ist nicht
die einzig existierende Wahrheit, die man als unfehlbares Dogma anbeten
müsste.
Georg
MaWin schrieb:> Uwe verweist aber auf den Artikel von Peter Dannegger in dem DEUTLICH> darauf hingewiesen wird, dass flankengetriggerze Auswertung nur Probleme> macht,
Aber Uwe != Uwe
Uwe S. schrieb:> encoder_read() bezieht sich auf eine Encoder-Implementierung von Peter> Dannegger (peda).> Den Code kannst hier im Forum finden oder auch hier mal nachsehen:>> https://www.mikrocontroller.net/articles/DrehgeberUwe schrieb:> zeigt ganz deutlich das du vom Tuten und Blasen keine Ahnung hast.> Auch "MaWin (Gast)" kann immer noch nicht zwischen Eingabegerät und> Messsystem unterscheiden. "Schlaue"/beleidigende Sprüche gehen aber> immer.
Der eine verweist auf den Peda-Artikel, der andere hält dich für einen
ähm, also, er ist nicht so überzeugt von deiner Meinung.
Und Uwe macht es auch auch mit Pinchange:
Uwe schrieb:> Auch ich benutze für Messsysteme 4-fach Auswertung mit PCI und das geht> wie Sau ohne Verlust von Impulsen.
mfg.
Georg schrieb:> Die Behauptung, dass jeder dumm ist, der nicht ständig Peter Danneger> liest, ist natürlich völlig absurd.
So ist es. P.D. sieht alles immer viel zu sehr aus der Perspektive
seiner Polling-Style-C-Programme.
D.h. aber wohlgemerkt keinesfalls, daß seine Pollinglösung für die
Quadratur-Encoder grundsätzlich schlecht oder ineffizient wäre. Das ist
sie natürlich nicht, sie ist im Gegenteil vollständig funktional, sehr
gut durchdacht und im gegebenen Kontext kaum effizienter umsetzbar.
Aber sie hat halt auch ihre Grenzen. Und zwar insbesondere bezüglich der
maximalen Erfassungsfrequenz/Schrittrate oder wie auch immer man das nun
nennen will.
Wenn diese sehr hoch wird (oder zumindest werden kann), muß natürlich
zwingend die Pollrate eine auf Polling basierenden Lösung dauerhaft
extrem hoch sein. Und dann führt ihre Anwendung sehr schnell dazu, daß
eine Anwendung garnicht mehr "geht".
Natürlich ist in einer Hochlast-Situation auch die Systemlast einer
interuptbasierten Lösung sehr hoch, u.U. sogar höher als die der
Polling-Lösung. Aber: Sie ist eben nur so lange so hoch, wie die hohe
Schrittrate anliegt und sinkt tendenziell bei Schrittrate 0 auf 0.
Das ist der entscheidende Unterschied und all die Spasten, die
gebetsmühlenartig ihre Bibel zitieren, sind scheinbar irgendwie völlig
unfähig, diesen simplen Sachverhalt zu begreifen...
Keine Ahnung, wer all diesen Typen derartig in's Gehirn geschissen hat.
Viele von denen sind eigentlich meiner Einschätzung nach durchaus in der
Lage, den Sachverhalt zu begreifen.
c-hater schrieb:> Keine Ahnung, wer all diesen Typen derartig in's Gehirn geschissen hat.> Viele von denen sind eigentlich meiner Einschätzung nach durchaus in der> Lage, den Sachverhalt zu begreifen.
Im Gegensatz zu dir haben die alle sogar begriffen, dass ein System,
wenn es Encoder erfassen soll die zur Zeit mit bis zu x Strichen drehen
können auch immer damit klarkommen muss wenn sie mal mit diesem Tempo
drehen - sprich die gesparte Rechenpower DARF nicht anderweitig
verschlissen werden, weil sonst die Auswertung fehlerhaft wird.
Und, weil alle ausser c-hater sogar mal in echt so was in Assembler
programmiert haben, wissen sie, dass die Polling-Lösung bei gegebener
Prozessorleistung immer die schnellere Drehzahl erlaubt, es fehlt
einfach der Interrupt-overhead.
Desweiteren haben alle anderen verstanden, dass prellende Drehgeber bei
der flankengetriggerten Interruptlösung zu vielen unnützen Interrupts
führen, deren Vermeidung extra Hardware erfordert.
c-hater schrieb:>> Die Behauptung, dass jeder dumm ist, der nicht ständig Peter Danneger>> liest, ist natürlich völlig absurd.>> So ist es. P.D. sieht alles immer viel zu sehr aus der Perspektive> seiner Polling-Style-C-Programme.
Hinzu kommt, daß sich seine Ausführungen auf Signale von mechanischen
Kontakten beziehen, die natürlich nicht so aussehen, die wie von
optischen Sensoren. Bei Letzteren gibt es kein 'Pendeln'(?) oder
Prellen, was man rot umrandet markieren müßte!
Und bei der Beschreibung von Problemen mit mechanischen Kontakten werden
irgendwelche Kurven gezeichnet. Mit der Realität haben diese erfundenen,
unbemaßten Signale nichts zu tun. Würde sich jemand mal die Mühe machen,
ein Oszillogramm davon hier einzustellen, könnte man sehen, was Sache
ist und ob die vermeitlichen Probleme überhaupt welche sind.
Bei mir sind es vornhemlich Sinussignale bis zu 100 kHz (MT12/25,
ST1207, ...), die auszuwerten sind. Wenn dort Prellen auftauchen würde,
hätte Heidenhain ein Problem ;-)
Im Grunde soll doch jeder machen, wie er will. Nur ist dort eine Grenze
überschritten, wo man Fragestellern derart diese eine Religion
einschreinen will, daß sie sich vor lauter Verunsicherung keine eigene
Meinung mehr leisten.
c-hater schrieb:> Viele von denen sind eigentlich meiner Einschätzung nach durchaus in der> Lage, den Sachverhalt zu begreifen.
Bei denen geht es darum, daß nicht sein kann, was nicht sein darf. Sie
haben einfach Angst, ihre Vorurteile revidieren zu müssen.
m.n. schrieb:> optischen Sensoren. Bei Letzteren gibt es kein 'Pendeln'(?)
Gerade bei denen kann das Wort 'Pendeln' sehr gut passen:
Vibrationen lassen die optische Sensorscheibe dicht am einem Übergang
von dunkel zu hell sich hin und her bewegen und lösen damit eine Unzahl
von elektrischen Impulsen in kurzer Zeit aus, weit schneller als z.B.
der Drehgeber je drehen könnte.
Eine Flankenauswertung muss damit viel schneller als die Strichfrequenz
bei maximaler Drehrate reagieren, damit kein Fehlzählungen auftreten,
eine polling-Variante hat mit den schnellen Übergängen keinerlei
Probleme.
m.n. schrieb:> Bei mir sind es vornhemlich Sinussignale bis zu 100 kHz (MT12/25,> ST1207, ...), die auszuwerten sind. Wenn dort Prellen auftauchen würde,> hätte Heidenhain ein Problem ;-)
Aber ggf. elektrische Einstreuungen. Auf das z.B. 10kHz Signal könnte in
kleiner Amplitude ein 100MHz Signal einstreuen und deine
flankengesteuerte Auswerteschaltung müsste die zählen. Beheben per
Schmitt-Trigger, das funktioniert aber nur so lange die Hysterese
grösser ist als die Einstreuungsamplitude.
Da gerade du hier die falsche Aussage verbreitest, flankenerkennung wäre
genau so einsetzbar wie polling, verhinderst du aber daß Leute bemerken,
daß bei flankengesteuerter Auswertung dieser Schmitt-Trigger zusätzlich
nötig wäre, so wie bei ihr bei mechanischen Kontakten zusätzlich eine
Entprellung nötig ist.
m.n. schrieb:> Im Grunde soll doch jeder machen, wie er will.
Du kannst sicher die Dinge machen wie du willst. Bloss anderen gegenüber
Lügnereien zu verbreiten durch Verschweigen der Probleme deiner Methode,
dem muss entgegnet werden. Aber manche Kirchenleute wollen keine
Aufklärung zulassen sondern beschimpfen die Aufklärer als Ketzer.
MaWin schrieb:> dieser Schmitt-Trigger zusätzlich> nötig wäre
Bei den AVRs sind die Eingänge doch schon Schmitt-Trigger. Hab jetzt
nicht in jedem einzelnen Datenblatt nachgeschaut, aber beim ATmega328
ist es zumindest so.
Weil sich das hier (schon wieder mal) nur zur lokalen Schlammschlacht
der bekannten Gesichter entwickelt hat, und die sich darüber jede Woche
mindestens einmal einen solchen nutzlosen Schlagabtausch liefern -->
gesperrt
Wenn mir einer eine PN mit einer richtig guten Begründung schickt,
dann mache ich den Thread gern wieder auf.
TEK00007.PNG
(4,7 KB)
