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
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:> 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.
