Hallo, ich habe folgendem Datenblatt den Encoder 110511, den ich gerne auswerten würde: http://www.maxonmotor.de/medias/sys_master/8806565412894/13_305-306_DE.pdf Jetzt habe ich in einem anderen Beitrag im Forum gelesen, dass es zu Problemen führen kann, wenn ich diesen Encoder bei einer maximalen Drehzahl von 10000Umd/min über die Interrupt Eingänge auswerten möchte. Das bedeutet an meinem Atmega 8 wären bei 10000 Umd/min 83333 Imp/s, die er über die Interrupeingänge auswerten müsste. Ich takte den Controller mit 16Mhz. Ich bin mir leider nicht im klaren, wie schnell er die Interrupeingänge abtasten kann und dadurch die Drehzahl berrechnen kann. Geht sich das aus? Andernfalls könnte man das Problem ja auch vielleicht mit einem Counter IC lösen oder? Danke für eure Antworten! Liebe Grüße
testuser schrieb: > Jetzt habe ich in einem anderen Beitrag im Forum gelesen, dass es zu > Problemen führen kann, wenn ich diesen Encoder bei einer maximalen > Drehzahl von 10000Umd/min über die Interrupt Eingänge auswerten möchte. Es kann deshalb zu Problemen führen, da evtl. die Interruptlast so groß wird dass Dein Hauptprogramm nicht mehr/nicht mehr richtig ausgefürht wird. testuser schrieb: > Das bedeutet an meinem Atmega 8 Muss es ein ATMEGA8 sein? Es gibt auch Controller mit integriertem Quadraturencoder...da macht Dir die ganze Arbeit die Logik im Controller. Dir würde also die volle Performance des Controllers zur Verfügung stehen. testuser schrieb: > Andernfalls könnte man das Problem ja auch vielleicht mit einem Counter > IC lösen oder? Für Geschwindigkeit brauchst Du ja Impulse pro Zeiteinheit oder Zeit zwischen Impulsen. Du müsstest also entweder einen freilaufenden Timer haben der bei steigender Flanke startet und bei der nächsten steigenden Flanke stopt --> Timerinhalt = Periodendauer. Oder Du bräuchtest einen Zähler der z.B. alle Sekunde zurückgesetzt wird. Bei jedem Reset müsstest Du dann den Zählerinhalt latchen. Das wären dann die Impulse pro Sekunde --> Rückrechnung auf Geschwindigkeit in RPM. Normalerweise verwendet man eine Kombination aus beiden Verfahren. Also bei langsamen Geschwindigkeiten misst man die Zeit zwischen Impulsen, bei schnellen Geschwindigkeiten misst man die Impulse pro Zeiteinheit.
> Muss es ein ATMEGA8 sein? Es gibt auch Controller mit integriertem > Quadraturencoder...da macht Dir die ganze Arbeit die Logik im > Controller. Dir würde also die volle Performance des Controllers zur > Verfügung stehen. Nein, es muss nicht unbedingt ein ATmega 8 sein. Leider kenne ich keinen mit einem Quadraturencoder. Kennst du von Atmel Controller die eine solche Logik haben? Aus der ATMEGA oder XMEGA Serie? Wenn ich einen solchen Kontroller verwende, so würde mir dann die Quadraturencoder Logik die Drehrichtung und für die Geschwindigkeit ein Taktsignal ausgeben oder? Wie wäre es dann intelligent im Programm vorzugehen? Also auf die Weise mit dem Timer mit Flankenauswertung oder einen Counter, der über einen fixen Zeitraster zählt? Danke für deine Hilfe. Grüße
ATxmega128A1, läuft allerdings nur mit 3,3V und kann max. 16Bit in Hardware
Hi >Kennst du von Atmel Controller die eine >solche Logik haben? Aus der ATMEGA oder XMEGA Serie? Haben alle XMega. MfG Spess
Für die Enddrehzahl ist der Encoder schlicht zu hochauflösend. Hat der Motor keine Hallsensoren, die du auswerten kannst? Oder musst du mit der Drehzahl auch noch weit runter regeln können? Mit freundlichen Grüßen Thorsten Ostermann
@ testuser (Gast) >Das bedeutet an meinem Atmega 8 wären bei 10000 Umd/min 83333 Imp/s, die >er über die Interrupeingänge auswerten müsste. Sehtr viel für eine Softwareauswertung. Zuviel. >wie schnell er die Interrupeingänge abtasten kann und dadurch die >Drehzahl berrechnen kann. Geht sich das aus? Nutze für niederige Drehzahlen die Encoderfunktion und für hohe Drehzahlen das Indexsignal.
testuser schrieb: > Nein, es muss nicht unbedingt ein ATmega 8 sein. Leider kenne ich keinen > mit einem Quadraturencoder. Kennst du von Atmel Controller die eine > solche Logik haben? Ich nutze mehr die Piccolos von TI. Da z.B. der TMS320F28032. Hier ein UserGuide mit ein paar Erklärungen: http://www.ti.com/litv/pdf/sprufk8 Oder die NXP Fraktion hat das auch drin: http://www.nxp.com/documents/user_manual/UM10360.pdf STM natürlich auch...
testuser schrieb: > Wenn ich einen solchen Kontroller verwende, so würde mir dann die > Quadraturencoder Logik die Drehrichtung und für die Geschwindigkeit ein > Taktsignal ausgeben oder? Drehrichtung und (teilweise) schon "fertige" Geschwindigkeit.
Hallo, schon mal vielen Dank für die ganzen Antworten. Als Kontroller würde ich doch lieber für dieses Projekt bei einem ATmega bleiben, da ich einfach viel mehr Erfahrung mit denen schon gemacht habe. Das bedeutet ich würde eher auf einen fertigen IC tendieren, der mir die Drehrichtung und die Drehzahl zum ATmega weiter gibt. Kennt ihr da einen IC der das schafft? Möglicherweise kann ich auch einen Atmega verwenden, der noch schneller als 16Mhz taktet. Ich habe auch einen Indexausgang am Drehgeber. Für was wird der in der Praxis verwendet? Kann man den in Bezug auf mein Problem gut einsetzen? Danke!
@ testuser (Gast) > >Ich habe auch einen Indexausgang am Drehgeber. Für was wird der in der >Praxis verwendet? Um den Winkel 0° zu erkennen, das kann ein normaler Drehgeber nämlich alleine nicht. Er liefert exakt einen Puls pro Umdrehung, der genauso breit ist wei ein Codeschritt des Encoders. > Kann man den in Bezug auf mein Problem gut einsetzen? Beitrag "Re: Maxon Encoderauswertung"
> über die Interrupeingänge auswerten
Wurde schon gefühlt eine Million im Forum erwähnt, dass Interrupt bei
Encoder-Auswertung Blödsinn ist.
UNd überhaupt, willst Du Position oder Geschwindigkeit messen?
> Um den Winkel 0° zu erkennen, das kann ein normaler Drehgeber > nämlich alleine nicht. Er liefert exakt einen Puls pro Umdrehung, der > genauso breit ist wei ein Codeschritt des Encoders. Alles klar, aber den sollte es ja möglich sein ab einer gewissen Drehzahl, bei der der Kontroller Probleme kriegt einfach auf den Indexkanal zur Auswertung umzusteigen. Das bedeutet ich habe dann für obere Drehzahlen viel weniger Auflösung. Bei 10000Umd/min wären das dann genau 10000Imp/min am Indexkanal und somit eine Frequenz von 166 Hz. Ab welcher Drehzahl denkst du sollte man von der Encoderfunktion zum Indexsignal wechseln? Ist das Indexsignal ausreichend für eine halbwegs genaue Drehzahlbestimmung im oberen Drehzahlbereich? Bezüglich der Auswertung der Drehrichtung könnte ich doch auch einfach D-FlipFlops verwenden. Schaffen die die hohe Impulsrate? Danke!
testuser schrieb: > Das bedeutet ich würde eher auf einen fertigen IC tendieren, der mir die > Drehrichtung und die Drehzahl zum ATmega weiter gibt. > Kennt ihr da einen IC der das schafft? Wenn Du ihn verwenden möchtest, kann ich Dir einen THCT12024 schenken. Der schafft ein paar MHz und wird parallel über einen 8-Bit-Bus ausgelesen. Oder man verwendet einen separaten AVR (ATmega48) und liest ihn per IIC-Bus aus. Hier eine Schaltung, mit der man 100kHz Quadratursignale erfassen kann: http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm Der OPV samt Beschaltung wird bei Rechtecksignalen nicht benötigt. Bei Bedarf könnte man die Eingangssignale per D-FF mit 400kHz synchronisieren, was aber in der Regel nicht nötig ist, wenn diese von einem optischen Drehgeber oder Hallsensoren kommen. Genervter schrieb: > Wurde schon gefühlt eine Million im Forum erwähnt, dass Interrupt bei > Encoder-Auswertung Blödsinn ist. Und es stimmt dennoch nicht!
> UNd überhaupt, willst Du Position oder Geschwindigkeit messen?
Es geht mir nur um die Geschwindigkeit.
So gut jetzt habe ich drei Varianten, die in Frage kommen.
1) Die mit dem Texas IC...
2) Atmega48 @ 20Mhz mit Auswertung von A/B und bei hohen Drehzahlen
Indexsignal
3) externer Atmega48@20Mhz der mir über I2C die Daten an meinen
Hauptkontroller schickt.
Leider bin ich mir nicht im klaren welche Variante ich verwenden soll...
testuser schrieb: > Es geht mir nur um die Geschwindigkeit. Wie genau und wie schnell möchtest du die Geschwindigkeit erfassen? Falls es ausreicht, würde ich dann nur das Indexsignal nehmen. Das Indexsignal lässt sich dann z.B. an einen Impuls Capture Pin anschließen und man müsste mit aktiviertem Timer nur ein Register für die Geschwidigkeit (eigentlich die Zeit für eine Umdrehung) auslesen. Man muss halt gegenenfalls den Timervorteiler anpassen, um eine hinreichend gute Auflösung zu bekommen.
Floh schrieb: > testuser schrieb: >> Es geht mir nur um die Geschwindigkeit. > > Wie genau und wie schnell möchtest du die Geschwindigkeit erfassen? > > Falls es ausreicht, würde ich dann nur das Indexsignal nehmen. Das > Indexsignal lässt sich dann z.B. an einen Impuls Capture Pin anschließen > und man müsste mit aktiviertem Timer nur ein Register für die > Geschwidigkeit (eigentlich die Zeit für eine Umdrehung) auslesen. > Man muss halt gegenenfalls den Timervorteiler anpassen, um eine > hinreichend gute Auflösung zu bekommen. Hm ja die Drehzahl sollte schon auf 10-20Umd/min genau sein. Würde sich das ausgehen?
@ testuser (Gast) >obere Drehzahlen viel weniger Auflösung. Bei 10000Umd/min wären das dann >genau 10000Imp/min am Indexkanal und somit eine Frequenz von 166 Hz. Jo. Das ist fast Zeitlupe. >Ab welcher Drehzahl denkst du sollte man von der Encoderfunktion zum >Indexsignal wechseln? Das haben wir mal im 4. Semester in Messtechnik berechnet. Ganz einfach. Nämlich dann, wenn die Signalfrequenz höher als deine Referenzfrequnez ist, in diesem Fall der Takt deines Mikrocontrollers. >Ist das Indexsignal ausreichend für eine halbwegs genaue >Drehzahlbestimmung im oberen Drehzahlbereich? Mal gerechnet? Bei 10 MHz CPU-Takt kann man 166 Hz/6ms über eine Periodendauermessung auf +/-100ns genau bestimmen, das sind 100ns/6ms = 16,6ppm oder 0,0016% bzw. 0,16 U/min. Wo macht man nun den Schnitt? Bei langsamen Drehzahlen wird die Periodendauer recht groß, das kann man zwar sehr hochauflösend messen, es dauer aber deutlich länger. Der Encoder liefert 500 Pulse/U, d.h. er hat die 500fache Frequenz, die Periode ist somit 500 mal kürzer im Vergleich zum Indexsignal. Nun must du festlegen, welche maximale Messzeit du haben willst. 100ms? 1s? Daraus kannst du dann errechnen, bei welcher Drehzahl du von Encoder auf Indexmessung umschalten musst. >Bezüglich der Auswertung der Drehrichtung könnte ich doch auch einfach >D-FlipFlops verwenden. Schaffen die die hohe Impulsrate? Locker. Aber das allein reicht nicht, man muss die dekodierte Information auch sinnvoll weiterverarbeiten. Für eine Drehzahlmessung braucht man auch einen Inkremantalgeber.
> Nun must du festlegen, welche maximale Messzeit du haben willst. 100ms? > 1s? Daraus kannst du dann errechnen, bei welcher Drehzahl du von Encoder > auf Indexmessung umschalten musst. Ja ist für mich leider relativ schwer zu sagen, da ich die Drehzahl im späteren auch noch regeln möchte. Ich bin mir leider nicht sicher wie schnell ich die Drehzahl neu bestimmen muss um eine gute Regelung der Drehzahl zu ermöglichen. > Locker. Aber das allein reicht nicht, man muss die dekodierte > Information auch sinnvoll weiterverarbeiten. Für eine Drehzahlmessung > braucht man auch einen Inkremantalgeber. Ja ist klar. Ich wollte mit den FlipFlops nur die Drehrichtung auswerten. Die Drehzahl muss dann natürlich noch ermittelt werden.
fang mal klein an und bau erstmal eine einfache Sache. Die Drehzalmessung. Sagen wir mit 100ms Messzeit. Das sind 10 Hz bzw. 600U/min. Darunter schaltest du auf die Encodermessung um, der liefert dann 5kHz. Mit der Input Capture Funktion kann man das sehr einfach sehr genau messen. Wenn das mal halbwegs läuft, kannst du die Regelung angehen.
Für niedrige Drehzahlen kannst du die klassische Softwareabtastung beider Encoder-Kanäle verwenden. Für hohe Drehzahlen lässt du die Pulse eines der beiden Encoder-Kanäle von einem Hardware-Zähler des ATmega zählen (der ist schnell genug). Damit ist bei hohen Drehzahlen zwar keine Richtungserkennung mehr möglich, aber bei hohen Drehzahlen ist auch keine Richtungsänderung zu erwarten.
Wenn ich es richtig verstanden habe, wird die Position des Motors gar nicht gebraucht, sondern nur Drehrichtung und Drehzahl. Die Drehzahl kann mit einem ATmega48 gemessen werden - direkt ein Kanal des Drehgebers. Selbst mit AVR-GCC sind ohne Vorteiler rund 300kHz meßbar. Die Drehrichtung auszuwerten, ist ein Klacks, indem bei jeder aktiven Flanke des Meßsignals der Pegel des anderen Kanals gespeichert wird. Beitrag "einfache Drehzahlmessung mit ATmega88" Und wenn doch noch die Position ermittelt werden sollte, würde ich eher einen weiteren ATmega48 verwenden, als zur Laufzeit verschiedene Auswerteverfahren umzuschalten. Anstatt IIC-Bus könnte man auch SPI verwenden, was schnellere Datenübertragung zuließe.
M. N. schrieb: > Wenn ich es richtig verstanden habe, wird die Position des Motors > gar > nicht gebraucht, sondern nur Drehrichtung und Drehzahl. Ja genau! > Die Drehzahl kann mit einem ATmega48 gemessen werden - direkt ein Kanal > des Drehgebers. Selbst mit AVR-GCC sind ohne Vorteiler rund 300kHz > meßbar. > Die Drehrichtung auszuwerten, ist ein Klacks, indem bei jeder aktiven > Flanke des Meßsignals der Pegel des anderen Kanals gespeichert wird. > Beitrag "einfache Drehzahlmessung mit ATmega88" Okey! Danke für die Info. Wie soll das Programm dann genau ablaufen, dass es gut funktioniert? Einen Timer mit einem bistimmten Zeitfenster laufen lassen und dauernd die steigenden Flanken zählen und dadurch dann die Drehzahl ermitteln oder? In welchem Betriebsmodus soll der Timer laufen? Input Capture Funktion? > Und wenn doch noch die Position ermittelt werden sollte, würde ich eher > einen weiteren ATmega48 verwenden, als zur Laufzeit verschiedene > Auswerteverfahren umzuschalten. Anstatt IIC-Bus könnte man auch SPI > verwenden, was schnellere Datenübertragung zuließe. Fürs erste mal nicht! Was haltest du von der Variante Falk?
testuser schrieb: > Wie soll das Programm dann genau ablaufen, > dass es gut funktioniert? Hast Du Dir das Beispielprogramm angesehen? Da läuft die Messung über die capture-Funktion von Timer1. Ferner gibt es eine Konstante MESSZEIT, die mit dem Wert 100 dafür sorgt, dass nach ca. 330ms eine Bewertung der Drehzahl erfolgt. In dieser Zeit werden die Eingangsimpulse gezählt und synchron dazu die Zeit gemessen. Es werden daher nie mehr als 3 Messungen/s gemacht. Setzt man den Wert auf 1, werden ca. 300 Messungen/s ausgeführt - unter der Voraussetzung, dass die Signalfrequenz hoch genug ist. Für eine Messung ist schließlich mindestens ein Intervall notwendig. Da man die LCD-Ausgabe weglassen kann, ist diese Meßrate auch kein Problem und kann auch 1000 Messungen/s betragen. Die Berechnung in 'float' ist hinreichend schnell und für die Ausgabe reicht es vermutlich, den Wert für die Drehzahl auf 16 Bit zu reduzieren. Die Drehrichtung kann man nachfolgend dem Befehl 'count++;' ermitteln.
Das Problem mit der Softwareabtastung entsteht bei schnellen Änderungen der AB-Signale. Hier gibts Lösungen mit schnellen Zähler dafür: http://www.ichaus.biz/wp2_encoderanschluss die das Problem beschreiben und lösen.
Ich habe noch eine Frage M.N. Ich habe noch Unklarheiten bezüglich des Beispielschaltplans bei deiner einfachen Drehzahlmessung mit Atmega 88. 1) Du sagtest zu mir ich soll es über den Input Capture Pin machen. In deinem Beispiel bist du aber am Interrupteingang. Wiso? 2) Ich verstehe nicht was die Diode D1 bei einem TTL Signal soll. Die ist ja in Sperrichtung gepolt. Also für meine Schaltung denke ich, dass es reicht den Kanal A mit PB0 (ICP) zu verbinden und Kanal B mit einem anderen x beliebigen Pin oder? Damit sollte dann die Auswertung der Drehzahl und der Drehrichtung möglich sein oder? Danke M.N.
Zu 1. Das capture-Signal von Timer1 kann von ICP1 (PB0) oder vom Analogkomparator kommen. Bei der gezeigten Schaltung ist es der Komparator. Nimm einfach ICP1. Zu 2. In Verbindung mit R4 und C3 wird die negative Flanke des Eingangssignals erfaßt und die max. Eingangsfrequenz begrenzt. Ausführlicher (für einen ATtiny2313) ist das hier beschrieben: http://www.mino-elektronik.de/fmeter/fmeter.htm#schalt Falls es zu verwirrend ist, ignoriere den nächsten Link. http://www.mino-elektronik.de/7-Segment-Variationen/LCD.htm#led2 Hier ist ein fertiges Programm, was Du auf einen ATmeg328 spielen und auf einem Steckbrett testen kannst. Das Eingangssignal wird hier an AIN1 erwartet und das Ergebnis per UART ausgegeben. Den vielen Rest und die 7-Segementanzeige kannst Du weglassen. Wenn Du AVR-Studio verwendest, kannst Du die Umrechung auf Drehzahl ergänzen (frequenz *= 60.0;) und auch für einen ATmega48 übersetzen. Ferner ist die Auswertezeit in 'ms'-Schritten einstellbar.
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.