Motor-Encoder erzeugt bei hohen Drehzahlen Fehlern

[Xaver]

Hallo zusammen,
[right:abd365b507]http://3.bp.blogspot.com/_qPTJUGegS5w/RfvkFxfGqDI/AAAAAAAAABE/nWNJ4RsGsVU/s200/DSC00519.jpg[/right:abd365b507]


mein Bruder und ich habe Probleme mit unseren Encodern und wir wissen noch nicht einmal ob es ein Denk, Rechen oder Mechanischer Fehler ist. Die Encoder haben wir auf unserem Blog wsgs.blogspot.com (http://wsgs.blogspot.com/2009_01_01_archive.html) ausführlich beschrieben.

Es handelt sich um Encoder für RB-40 Motoren, die am Ende des Motors befestigt werden. Zwei Gabellichtschranken und eine Schlitzscheibe erzeugen zwei um 90° verschobene Signale. Ein Schmitttrigger säubert die Signale für einen µC. Die Auswertung wird durch einen der neueren ATmega328P durchgeführt. Dessen Eingänge lassen sich als Interrupt für steigende und fallende Flanke konfigurieren. Bei jeder Flanke von Signal A oder B wird die Interrupt Service Routine gestartet und die Drehung ausgewertet.
[right:abd365b507]http://1.bp.blogspot.com/_qPTJUGegS5w/SW98EhOdfNI/AAAAAAAAAHs/1M6r8rg5IF8/s320/DSC01080_filtered.jpg[/right:abd365b507]
Die Rechnung:
Da ich mich schon einige male verrechnet habe wollte ich euch bitten über meine Rechnung zu schauen. Meist hilft es ja schon, wenn man es ausführlich hinschreibt.
Die Schlitzscheibe hat 32 schwarze Felder. Bei jedem Feld werden 4 Flanken erzeugt (steigend, fallend Lichtschranke A und steigend, fallend Lichtschranke B). Der Motor macht bis zu 5000 Upm.

http://www.sitmo.com/gg/latex/latex2png.2.php?z=100&eq=5000upm%20%5Ccdot%2032%20%5Ccdot%204%20%3D%2010 667%5C%20ISR%2Fsec

Es werden also fast 11 tausend Interrupts pro Sekunde erzeugt. Der µC läuft deswegen mit 20Mhz und soll dabei zwei Motoren auswerten können (erst mal reicht einer).

http://www.sitmo.com/gg/latex/latex2png.2.php?z=100&eq=%5Cfrac%7B20000000%7D%20%7B10667%5C%20ISR%2Fsec %7D%20%3D%201875%5C%20Instruktionen%2FISR

Zwischen jedem Interrupt können also 1875 Maschienenbefehle ausgeführt werden. Nun hängt es von der ISR ab, wie viele Maschinenbefehle sie braucht und wie viele für andere Programmaufgaben übrig bleiben.

Die ISR
Die Interrupt Service Routine erzeugt zwei Werte die zum Test alle 100ms über UART ausgegeben werden.


public volatile long lEncoder;
public volatile long lError;

ISR(PCINT0_vect)
{
// lookup table
static const int8_t aSteps[] = { 0, -1, 1, ENC_INV, 1, 0, ENC_INV, -1, -1, ENC_INV, 0, 1, ENC_INV, 1, -1, 0 };
int8_t iStep = 0; // Schrittweite des Motors

// alte Phase um zwei Bit nach links verschieben
bPhase.bRow = (bPhase.bRow << 2);
// alles ausser a und b löschen
bPhase.bRow &= 0x0C; // 0000 1100 = 0x0C
// Signal A einlesen
bPhase.x.Signal_A = IS_SET_MOT1_SIG_A ? true : false;
// Signal B einlesen
bPhase.x.Signal_B = IS_SET_MOT1_SIG_B ? true : false;

// Schrittweite aus Tabelle auslesen
iStep = aSteps[bPhase.bRow];
if (iStep != ENC_INV)
{
lEncoder += iStep;
}
else
{
lError++;
}
}


Das Problem:
Wenn ich jetzt die Geschwindigkeit des Motors über 2000Upm hoch drehe kommen immer mehr Fehler (lError steigt), bis keine Auswertung mehr möglich ist. Ist der µC zu langsam für die Aufgabe? Oder kann man ihn noch etwas endlasten, wir ISR in Assembler oder Vorteiler?

Vielen Dank schon mal für eure Mühe
Guß Xaver

[ranke]

Einen offensichtlichen Fehler kann ich nicht erkennen, zumal man ja sieht, dass hier mit Bedacht und Sorgfalt gearbeitet wird.
Wonach ich in dieser Situation suchen würde:

1. Für die Reflexlichtschranke habe ich auf die schnelle keine Daten gefunden. Oft ist es im Ausgangsteil nur ein Fototransistor dessen Kollektor mit einem Widerstand an Plus gelegt wird. Eine solche Schaltung ist für höhere Frequenzen (steile Flanken) wenig geeingnet. Möglicherweise wird das Signal bei höheren Frequenzen derart verschliffen, dass die Interrupt-Schaltpunkte des uC nicht mehr erreicht werden, oder dass zufällige Störungen, die sich eingeschlichen haben, relevant für den Schaltpunkt werden.

2. Dein Rechenergebnis mit 1875 Instruktionen zwischen zwei Interrupts ist nur gültig, wenn die erzeugten Flanken der Lichtschranken genau symetrisch sind. Das sind sie in der Praxis natürlich nicht. Es kann also wesentlich knapper werden. Möglicherweise zu knapp. Eine mechanische Instabilität (z.B. Eigenfrequenz der Schlitzscheibe) könnte die Schaltpunkte auch zusätzlich verschieben, indem der Abstand Schlitzscheibe - Fototransistor nicht konstant bleibt.

3. Störungquellen über die Betriebsspannung, Motorzuleitungen etc. hast Du wahrscheinlich schon beseitigt (durch getrennte Leistungsversorgung von Motor und Elektronik, Entstörkondensatoren direkt am Motor, räumliche Trennung von Motor- und Meßleitungen).

[PicNick]

Würde auch überlegen, ob du überhaupt jede Motordrehung 32-mal messen mußt.
Wie weit bewegt sich denn der Robot bei einer 1/32 Motordrehung ?

[pongi]

Eine viel ressourcensparendere Möglichkeit wäre, die Impulse mit einem Timer zu zählen. Die Atmegas haben Timer, die extern getriggert werden, auf diesen Eingang legst du dann dein Signal an. Dann stellst Du einen Interrupt ein, der auslöst, wenn dieser Timer überläuft. Einen anderen Timer benützt du für die Zeitmessung.
Vorgangsweise:
-beide Timer starten bei 0, Timer1 wird extern getriggert, Timer2 über den Clock
-wenn Timer0 einen Überlauf hat, schaust du dir die verstrichene Zeit an, aus der Zeit und der bekannten Anzahl der Impulse kannst Du auf die Geschwindigkeit schliessen.
-ein Überlauf von Timer1 muss noch gehandelt werden, eigentlich hast du beim Überlauf von Timer1 auch eine Geschwindigkeit, denn da hast die fixe Zeit, und die Anzahl der Impulse kannst Du auslesen.

Wenn nicht genug Timer mit externer Triggerung vorhanden sind, könnte man vielliecht die Interruptroutine so verändern, dass in der Routine selbst nur eine Variable bei jedem Impuls erhöht wird (Software-Zähler). Nach einer bestimmten Zeit (Timer) wird dann die Anzahl der Impulse ausgewertet.

Weiter ist zu bedenken, (wie es schon Picknick geschrieben hat), ob eine solche Auflösung generell notwendig ist, denn wenn noch ein Getriebe nachgeschalten ist, ist die Auflösung am Rad definitiv viel zu hoch.

MfG

pongi

[oberallgeier]

Hi Xaver,


... Probleme mit ... Encodern ...Mehrere Dinge verstehe ich nicht.

Gut, ich habe (noch) kein invertierendes Pendel aufgebaut, aber ich weiß, dass hier eine gute Auflösung benötigt wird. Mit meinen kleinen Gabellichtschranken (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=344432#344432) löse ich eine Größenordnung weniger auf - 1500 Hz, allerdings wird bei mir nur (?) auf steigende Flanke getriggert. Die entsprechende Regelung läuft hervorragend. (https://www.roboternetz.de/phpBB2/viewtopic.php?p=390196#390196)

Als Denkfehler sehe ich an, dass Du direkt am Motor die Drehzahl erfasst >>>um das Lagerspiel auszublenden<<<. Ok, dann regelst Du den Motor - und kannst bei genügend guter Auflösung innerhalb des Lagerspiels regeln - dabei bleiben die Räder stehen *ggggg* und nur das Getriebe ruckelt hin und her, bei 1:100 schon eine denkbare Geschichte. Das bringts doch nicht!

... Dies sollte die größte Messgenauigkeit und schnellste Erfassung der Motoren ergeben, da das Lagerspiel nicht mit erfasst wird...
Wenn ich ein invertierendes Pendel aufbaue, würde ich erstmal auch nicht den Motor bzw. das Getriebe auf seine Abtriebsdrehzahl regeln (und schon garnicht ohne das Getriebespiel in die Regelung einzubeziehen), sondern eine Lageregelung aufbauen ungefähr so: kippt links => Motor rechts, kippt rechts => Motor links. Aber das ist ja DEIN Projekt.

Sehen wir doch mal, was die Regelung theoretisch bringt. Da Du keine Angabe über die Getriebeübersetzung machst, nehme ich versuchsweise an, dass Du ein Getriebe 1:100 hast. Du könntest also (nach Deinen Angaben: 32 Felder x 4 Flanken) über 12.000 ticks pro Radumdrehung auflösen (32 x 4 x 100). Geschätzter Raddurchmesser nach Deinem Blog-Bild: 60 mm => Auflösung theoretisch 15 tausendstel Millimeter (0,016). Wenn ich ohne Hemmungen sprechen darf: da vermute ich, dass das Unsinn ist - sorry - also: Frage: ist das nicht etwas hochgestochen? Wie mehrfach angedeutet: das Getriebespiel ist damit NICHT vom Erdboden - und es ist ausserhalb des angestrebten Regelkreises.


... Ein Schmitttrigger säubert die Signale für einen µC ...Uuuuups - wusste garnicht, dass ich soooo schlampig arbeite: meine Gabellichtschranke geht mit einem nicht allzu kurzen Kabel - entlang der PwM-versorgten Motorzuleitung - ohne sonstwas zum µC. Störungen: nicht erkannt. Dein Aufbau ist ja vermutlich sehr sauber - aber ist das notwendig/erforderlich?

So, das waren nur meine ersten Eindrücke - die helfen Dir vermutlich garnicht. Also brauchen wir noch einen Rat:

Rat 1:

... Die Interrupt Service Routine erzeugt zwei Werte die zum Test alle 100ms über UART ...Datenübertragung in einer ISR (? - wirklich in der ISR - oder doch ausserhalb?) von DER Frequenz. Junge Junge! Rechne mal den Zeitbedarf für die Datenübertragung. Oder - einfacher - schalte mal diese Datenübertragung ab und teste Deine Lichtschranke (Daten im Test abspeichern und offline übertragen).

Rat 2:
Lichtschranke 1 auf INT0, Lichtschranke 2 auf INT1. Triggern auf steigende Flanke. Nachteil: es könnte sein, dass Du so die Drehrichtungsumkehr schlechter mitbekommst. Vielleicht könntest Du nach dieser Methode aber erstmal das Ding nach Deinem Konzept zum Laufen bekommen - ist ja nur die halbe Interruptfrequenz.

Viel Erfolg - oder viel Glück

[pongi]

An der Uni musste ich auch eine Regelung für ein Doppelpendel entwerfen. Ich habe mich damals für eine absolute Messung des Winkels am Gelenk entschieden. Damit hats dann sehr gut funktioniert. Vielleicht überdenkt ihr das Konzept nocheinmal.

[oberallgeier]

In diesem Bericht (http://www.informatik.fh-wiesbaden.de/~linn/vpdv05/jopp_et_al/doku_pendel.pdf)wird (ebenfalls) über Messfehler beim Auslesen der Encoder berichtet, die nicht bereinigt werden konnten.

[Xaver]

Vielen Dank schon mal für eure Hilfe.

@ranke: Wie ich gerade sehe, gibt es diese sehr kleinen Lichtschranken (4x5x5mm) leider bei Pollin nicht mehr. Im Datenblatt (http://www.datasheetcatalog.org/datasheet/rohm/rpi-243.pdf) wird eine Reaktionszeit von 10µs versprochen, was 100kHz entspricht. Sollte also reichen. Ich kann aber leider nicht überprüfen wie sehr die Signale verschiffen werden, daher habe ich ja auch einen Schmitt-Trigger dahinter geschaltet. Die Hysterese sollte die Signale wieder verbessern.
Diesen Punkt werde ich aber sicher anschauen, wenn ich ein Oszi finde.
Das mit den nicht symmetrischen Flanken war mir auch bei meinen ersten Versuchen aufgefallen. Die Scheibe ist sicher nicht ganz eben und eiert ein ganz wenig. Auch ist es nicht leicht nur mit bloßem Auge die Lichtschranken an der Scheibe auszurichten. Ich dachte aber, dass dies kein Problem sei und nur die Dauer einer Periode zählt. Die Signalverläufe von A und B (http://2.bp.blogspot.com/_qPTJUGegS5w/SWeUrQd793I/AAAAAAAAAGk/OW2snjzm_68/s1600-h/4FachFlankenISR.jpg) sind nur etwas verschoben, so dass zwei Flanken dicht hintereinander kommen und dann eine längere Pause ist.
Kommen zwei Flanken dicht hintereinander, so wird bei der ersten, die ISR angestoßen und bei der zweiten der Interrupt zwar gesetzt, aber erst im Anschluss an die erste ISR bearbeitet. Dann liegen die Signale ja immer noch an und sollten daher auch richtig verarbeitet werden. Der dritte Interrupt kommt wieder ganz normal.

@pongi
Leider habe ich nicht so viele Timer in µC. Einen verwende ich bereits für die PWM, ein zweiter ist für periodische Abfragen (mach alle 100ms etwas) und die Uhrzeit zuständig. Der letze Timer wird wohl ein RC-Signal von einer Fernsteuerung auswerten und im Moment mache ich ja eigentlich auch nichts anderes als bei jedem Interrupt einen Zähler hochzusetzen und alle 100ms nachzuschauen welchen Wert dieser hat.

@oberallgeier
Noch ist unser Robi kein Pendel und er fährt ganz „normal“ mit Stützrad. Für die Regelung der Motoren ist es auch gar nicht von so großer Bedeutung, außer die nötige Reaktionszeit und die häufigen Richtungswechsel. Daher soll bei der Motorregelung dieses ja mit bedacht werden. Durch die häufigen Richtungswechsel müssen also beide Flanken ausgewertet werden, sonst gehen Richtungswechsel verloren. Naja und je schneller, desto besser.
Das mit dem Lagerspiel habe ich ehrlichgesagt gar nicht richtig bedacht ](*,) und du hast absolut recht, das es keinen Sinn macht die Motordrehung hoch genau zu messen, um hinterher das Lagerspiel auszuregeln.
Nun denn, ich habe eine Getriebeübersetzung von 1:40 und Reifen mit einem Umfang von 31cm.
http://www.sitmo.com/gg/latex/latex2png.2.php?z=100&eq=%5Cfrac%20%7B360%20%5E%5Ccirc%7D%7B32%20%5Ccdot %204%7D%20%5Ccdot%20%5Cfrac%7B1%7D%7B40%7D%3D0%2C0 7%5E%5Ccirc
Hmm, 0.07° Auflösung nach dem Getriebe, das ist ja echt verdammt wenig. Dann würde ich ja auch 0,06 mm Strecke messen können. Also mit Panzern auf Spatzen schießen kann man als Vergleich ruhig heranziehen. :-b
Die Übertragung der Daten wurde aber nicht in der ISR, sondern im Hauptprogram gemacht.

Ziel war es eigentlich die Regelung der Motoren alle 10 ms durchführen zu können. Das schnellst was wir geschafft haben waren aber 20ms (http://picasaweb.google.com/lh/photo/6fZdQEU5M_VSF2jWQPCUqg?feat=directlink) mit Fehlern. Wir haben mal das ganze in einem Diagramm aufgezeichnet. Der Motor ist ohne Belastung angeschlossen. Der Sollwert (grüne Linie) wird immer weiter erhöht, bei 255 gehalten und dann auf 0 gesetzt. Die lila Linie zeigt die Drehzahl des Motors in Flanken/20ms, wobei gut zu sehen ist, dass der Motor am Anfang noch etwas steht und sich dann der Solllinie nähert. Ab etwa 210Flanken/20ms (etwa 4900 upm) steigt der Fehlerzähler und die wirkliche Drehzahl wird nicht mehr richtig gemessen.

Fazit
Ich werde also die Schlitze auf 16 halbieren und die Regelung verlangsamen.

[oberallgeier]

Hallo Xaver,

schön, dass wir da einer Meinung über sinnvolle Genauigkeit (bzw. über Spatzen und Kanonen) sind.

... Ziel war es eigentlich die Regelung der Motoren alle 10 ms durchführen zu können ...Bei meinem Dottie wird mit 405 Hz (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=412112#412112) geregelt: da gibts ne Schaltfrequenz in meinem Aufbau, (https://www.roboternetz.de/phpBB2/download.php?id=15412) die allerlei macht - u.a. einen ADC auslesen. Der wird über 12 "Lesungen" gemittelt. Es lag nahe, in der Lesung 4 und 8 die Regelung laufen zu lassen - und in 12 rechne ich eben die ADC-Statistik. Langsamer regeln wäre mir egal gewesen - nur passte es eben so rein. Überrascht war ich eigentlich auch nicht, dass die integer-Regelung so exakt läuft (hab ich schon mal an einer ziemlich grossen Maschine ähnlich gemacht). Zumal meine Drehzahlmessung den "Überhang" an Zeit bei einer abzuwartenden Interruptbedienung dem nächsten Messwert zuschlägt. Da geht mir praktischerweise nix verloren. Bei der Geschwindigkeit von Dottie ist das, genaugenommen, (auch) mit Kanonen . . . das hatten wir ja gerade.

Ach so - die kleinen Gabellichschranken: ich verwende die GP1S096HCZ von Sharp - 2,9 mm x 2,6 mm x 3,5 mm, gekauft bei CSD (http://www.csd-electronics.de/de/index.htm) für etwas über 1/2€. Bestellnummer 20836.

[ranke]

Im Datenblatt wird eine Reaktionszeit von 10µs versprochen, was 100kHz entspricht. Sollte also reichen. Ich kann aber leider nicht überprüfen wie sehr die Signale verschliffen werden, daher habe ich ja auch einen Schmitt-Trigger dahinter geschaltet. Die Hysterese sollte die Signale wieder verbessern.


Hierzu noch ein paar schnelle Gedanken:

Bei der Berechnung der maximalen Frequenz verwechselst Du Anstiegszeit und Periodendauer. Fig. 7 und 10 des Datenblatts geben eine genauere Einsicht in die Anstiegszeit. Es ist also problemlos möglich Anstiegszeiten von deutlich über 100 us zu erreichen. Das Ganze wurde ohne kapazitive Last gemessen, diese ist in der Realität immer vorhanden, es könnte also doch kritisch werden.

Noch eine Überlegung zur Gleichspannungsanpassung des Fototransistors zum nachgeschalteten Schmitttrigger:
Bei höheren Frequenzen wird die Ausgangsspannung des Fototransistors - bedingt durch die endliche Anstiegszeit - erst trapezförmig, dann dreieckig, und mit zunehmender Frequenz nimmt die Amplitude des Dreiecks ab.
Durch die abnehmende Amplitude könnte es passieren, daß die Wechselspannung irgendwann nicht mehr die beiden Schaltschwellen des Schmitttriggers überstreicht.
Theoretisch sollte man dadurch einen schlagartigen Ausfall der entsprechenden Lichtschranke erwarten, in der Praxis werden (z.B. wegen mechanischer Toleranzen) immer erst einzelne Flanken verloren.



Kommen zwei Flanken dicht hintereinander, so wird bei der ersten, die ISR angestoßen und bei der zweiten der Interrupt zwar gesetzt, aber erst im Anschluss an die erste ISR bearbeitet. Dann liegen die Signale ja immer noch an und sollten daher auch richtig verarbeitet werden. Der dritte Interrupt kommt wieder ganz normal.


Da hast Du recht, ich hatte nicht bedacht, dass man Interruptroutinen verschachteln kann.

[oberallgeier]

Hi,


... Anstiegszeit und Periodendauer ...Die Schaltung von Xaver kenne ich nicht, trotzdem meine Anmerkung dazu. Bei der IR-LED SFH415 hatte ich bei dieser Schaltung (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=384868#384868) festgestellt, dass die Anstiegszeit des durchfliessenden Stromes (die ich als Maß für die Lichtintensität genommen hatte) einfach aber drastisch verkürzt werden kann (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=387767#387767) - das steht gegen Ende des Postings. Sprich: der Transistor schaltet deutlich schneller (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=384884#384884) durch, seine Schaltflanken werden "besser". Wenns interessiert, bitte auch die Folgepostings im ersten Link lesen bis zu den Oskarbildchen.

[Besserwessi]

Die 1800 Zyklen sollen für die ISR reichen. Wenn man will könnte man das ja noch etwas verlangsamen, indem man die Auflöung auf die Hälfe reduziert und nur eine der Flanken auswertet.

Das Problem solle wohl eher die Lichschranke sein. Die Anstigszeiten sind meistens für ziehmlich niedrige Lastweiderstände angegeben. Wenn man da direkt ein Logicsignal erzeugt ist der Wiederstnad aber deutlich größer und das ganze langsamer.

[oberallgeier]

Hi,

die Auswertung nur einer Flanke hat aber Auswirkungen bei der Drehrichtungsumkehr . . . .

[nestandart]

bei hoheren Umdrehungen habe ich auch schlechte erfahrung mit IR-encoder.
deswegen bin ich auf Hall-sensoren (AS5035) umgestiegen.

[oberallgeier]

Was heisst "hohe Umdrehungen" in Hertz? Das wäre jetzt interessant.

[nestandart]

oberallgeier, habe jetzt keine genauen angaben...
es waren aber ca 8-10 "sektoren" auf der Taktscheibe. Alles saß auf motorwelle ("Normaler" Motor... ca 2cm durchmesser, 4cm länge).
ab bestimmten Umdrehungszahl habe ich keine "vernunftige" daten bekommen. Damals habe ich vermutet, dass die Menge der IR-strahlung reichte nicht , um eindeutuges "schalten" des Fototransistors zu inizihiren : )
(Fenster in der Taktscheibe zu klein und/oder Drehgeschwindigkeit zu hoch)

Möglicherweise hilft es einfach IR-lichtstärke zu erhöhen... mehr Strom durch IR-Sendediode zu jagen.... das kostet aber mehr Batterie-Energie.

Also mit Hall-sensoren ist es Ökologischer :)

[drew]

Hallo Xaver,
hast Du Dir eigentlich schon mal die Signale (vor und nach Schmitttrigger) auf einem Oszi angeschaut?

Bei Drehrichtungserkennung (auf eine Flanke) schau ich immer nur auf den anderen Eingang. Wenn der high ist, geht's in die eine Richtung (+1), sonst eben in die andere (-1).

Drew

[melchi]

Moin moin Zusammen!
Da die Probleme erst in den höheren Drehzahlbereichen (Leerlauf) auftreten und diese im „Betrieb“ eher weniger auftreten (vielleicht wenn der Bot eine Schräge runter fährt) stimme ich dafür dies ein nicht sehr kritisches Problem ist. Doch möchte ich hier gerne die schnellste genauste Möglichkeit haben.
OK 0,06mm klingt erstmal wenig. Ist ja auch kein realer Wert, da ist wieder das Getriebespiel, das mit ca. 2 bis 3° den Wert der möglichen Genauigkeit auf gute 2,5mm bringt.
Sicher ist die Messung direkt am Motor die damit verbundene Integration des Getriebespiels in den Regelkreis nicht ideal, doch lässt sich dieser in der Regelung berücksichtigen (denk ich) und eine GetriebeZitterRegelung vermeiden.
Wir haben es geschafft die Schaltung nun mal unter einem Oszi anzuschauen. Bilder und Videos findet ihr auf dem Blog http://wsgs.blogspot.com/

[melchi]

Ich habe da doch noch eine Frage!
Es gibt viele Encoder die mehr als 100 Impulse/Umdrehung haben, einige habe sogar 1000 Impulse/Umdrehung und die Motoren drehen mit 4000-6000 Umdrehungen/Minute. Nun meine Frage!

Wie werten die das aus? Ich möchte nicht wissen wie eine klassische Vierfachauswertung funktioniert. Ich wüsste gerne mit welcher Hardware die es schaffe diese Encoder auszuwerten. Haben die einen Trick?

Danke schon mal für euer Wissen!

Schön Gruß
Der Melchi

[oberallgeier]

Ich habe Motoren die drehen max. über 750 Hz (also bis zu 45000 Upm) und deren Encoder gibt 2 Peaks pro Umdrehung. Diese 1500 Hz sind kein Problem - da ich 2 Motore habe, sind das schon mal rund 3000 ISR pro Sekunde - - - - alle Zeit der Welt bei (m)einem 20 MHz-Controller. Ausgewertet wird - siehe mein Posting oben vom 22 Jan 2009, 10:47, bei "Rat 2: ..."

[melchi]

Ja bei nur 2 Impulsen pro Umdrehung hast du echt alle Zeit der Welt!

Zum Rat 2: Nur auf steigende Flanken reagieren bedeutet keine klassische Vierfachauswertung eigentlich nicht unser Ziel. Du hast doch alle Zeit der Welt warum benutzt du nicht jede Flanke?

Wie schaffen es die Hersteller Encoder mit 1000 Pulse pro Umdrehung auszuwerten bei Motoren mit 4000 Umdrehungen pro Minute?
Verwenden die ein CPLD oder einen Hardware Counter?

[oberallgeier]

... Du hast doch alle Zeit der Welt warum benutzt du nicht jede Flanke? ...Das ist ganz einfach: ich mache nicht das irgendwie Mögliche, sondern das zielführend Nötige. Die Auslegung der Geschichte wird durch den sehr sauberen Geradeauslauf des R2D03/Dottie (http://www.youtube.com/watch?v=sRNSIBpK8sQ) bestätigt: auf 1 m Laufstrecke weicht der weniger als +/- 1 mm von der geraden Linie ab. Warum also mehr machen ?


... Wie schaffen ... 1000 Pulse pro Umdrehung ... mit 4000 Umdrehungen pro Minute ...Deine Zahlen ergeben rund 67 kHz. Meine ISR zur Auswertung EINES Encoderpeaks hat - mal oberflächlich gezählt - knapp 60 Maschinenzyklen einschließlich aller push´s und pop´s. Bei meinen 2 Encodern dieser Art und meinem Controller m168 mit 20 MHz wären also 167 kHz drin. Dabei habe ich sogar eine softwaremässige Abfrage der Flankenabstände, um Spikes durch Störungseinflüsse abzufangen. Wo also sollte das Problem liegen? Wie gesagt - die Auslegung ist eine sinnvolle Arbeit. An ihrem Anfang steht die geringe Mühe, sich mit dem System vertraut zu machen. Systemanalyse macht vielleicht nicht jeder . . . .