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
Angehängte Dateien:
-
TEK00007.PNG
4,7 KB
:
Gesperrt durch Moderator
@ 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!
Bei diesen schnellen Signalen mußt Du per Interrupt auswerten. Hier eine Möglichkeit mit dem ATmega48: Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88" Wenn Du nur ein IC dazwischenschalten möchtest, kannst Du es so machen: Beitrag "mini Quadraturdekoder + 32 Bit Zähler + TWI, Attiny25"
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
Falk B. schrieb: > Das gilt allgemein, auch wenn einige Leute das in religiösem Eifer > anzweifeln Hat da wieder einer Jehova gesagt?
Angehängte Dateien:
-
TEK00008.PNG
5,4 KB -
TEK00009.PNG
5,4 KB
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.
:
Bearbeitet durch User
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).
Angehängte Dateien:
-
DiffSig.png
5,2 KB
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.
:
Bearbeitet durch User
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.
Michael B. schrieb: > Flattereffekten Schreibt sich das nicht 'flutter'? Oder anders gefragt: "Was ist denn das?"
@ 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.
:
Bearbeitet durch User
@ 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"
:
Bearbeitet durch User
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.
Oder (ohne Dein Listfile gesehen zu haben) tatsächlich die wenigen Zeilen für den Drehgeber in Assembler schreiben.
Oder man nimmt einen 2. AVR als Dekoder. Beitrag "Re: Versetzte Rechtecksignale auswerten, kein drehgeber"
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 | void encoderISR_A(void){ |
2 | if(enableInterrupt == 1){ //for disabling interrupt after 1 execution (to avoid jitter) |
3 | setEncoderPosition(); |
4 | enableInterrupt = 0; |
5 | }
|
6 | }
|
7 | |
8 | void encoderISR_B(void){ |
9 | if(enableInterrupt == 0){ //for disabling interrupt after 1 execution (to avoid jitter) |
10 | setEncoderPosition(); |
11 | enableInterrupt = 1; |
12 | }
|
13 | }
|
14 | |
15 | void setEncoderPosition(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.
:
Bearbeitet durch User
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?
Wikipedia: > Pendeln steht für: > ... > der Gebrauch eines Pendels in der Esoterik, siehe Pendel (Esoterik) > ... SCNR
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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: > Es geht doch, wie man sieht! So lange man es nicht per dummer flankenausgelöster Interrupts macht, geht das natürlich problemlos.
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.
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/Drehgeber Uwe 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.
Thomas E. schrieb: > Aber Uwe != Uwe Das ist natürlich blöd, dass ich das übersehen habe, erklärt aber warum der eine Uwe so klug und der andere so dumm rüberkam. Georg schrieb: > es gibt sogar ICs dafür Sicher kein einziger flankengetriggert, alle mit Takt http://www.lsicsi.com/encoders.htm (LS7082/7083/7084/7182/7183/7166/7266/7366) http://www.avagotech.com/docs/5988-5895EN (HCTL2000/2016/2020/2022/2032)
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.
Thread beobachten
Seitenaufteilung abschalten