An einem Motor mit Getriebe befindet sich auf der Motorachse der Drehgeber/Encoder. Durch das Getriebe ergeben sich auf der Abtriebsachse 1.200 Steps pro Umdrehung. Bei einer Drehzahl von 500 U/min ergeben sich 10.000 Steps/Sekunde. Lt. Drehgeber-Artikel müsste ich also mit 200kHz abtasten. Das ist zuviel. Idee: einfach mit zwei Binär-Zählern die Signale durch 16 teilen. Frage: Hat jemand dieses Problem in der Praxis so gelöst? Oder anders? Lösungen mit FPGA, CPLD & Co. scheiden mangels Technik und Synapsen aus.
@Thomas Z. (tezet) >An einem Motor mit Getriebe befindet sich auf der Motorachse der >Drehgeber/Encoder. Durch das Getriebe ergeben sich auf der Abtriebsachse >1.200 Steps pro Umdrehung. Bei einer Drehzahl von 500 U/min ergeben sich >10.000 Steps/Sekunde. Was sind bei dir Steps? Codewechsel oder Puls auf dem Signal. Das wird oft vermischt. >Idee: einfach mit zwei Binär-Zählern die Signale durch 16 teilen. Nö, das geht nur, wenn man EINEN Kanal als einfachen Drehzahlgeber nutzen will. Will man aber die Encoderfunktion erhalten, geht nichts an einem echten Decoder vorbei. >Lösungen mit FPGA, CPLD & Co. scheiden mangels Technik und Synapsen aus. Dann nimmt old school CMOS, Lösung ist im Artikel enthalten. Oder nimm einen passenen PIC/AVR whatever, der so einen Decoder als Hardware drin hat. Oder einen, mittlerweile eher schwer erhältlichen Decoder-IC mit SPI oder sonstiger Schnittstelle.
Falk Brunner schrieb: > Was sind bei dir Steps? Codewechsel oder Puls auf dem Signal. Das wird > oft vermischt. Gute Frage. Zitat: "an integrated quadrature encoder that provides a resolution of 64 counts per revolution of the motor shaft, which corresponds to 1200 counts per revolution of the gearbox’s output shaft" Link: http://www.pololu.com/catalog/product/1442 > Dann nimmt old school CMOS, Lösung ist im Artikel enthalten. Das habe ich befürchtet oder Umstieg auf XMega Danke
@ Thomas Z. (tezet) >Gute Frage. Zitat: "an integrated quadrature encoder that provides a >resolution of 64 counts per revolution of the motor shaft, which >corresponds to 1200 counts per revolution of the gearbox’s output shaft" Ist nicht eindeutig, das könnten 1200 Takte bzw. 4800 Codes sein, aber auch nur 1200 Codes. Man weiß es nicht. Was willst du denn mit dem Ding machen? Positionierung?
Falk Brunner schrieb: > Was willst du denn mit dem Ding machen? Positionierung? Einfach einen kleinen Roboter (Hobby/Entspannung). Es geht eher um kurzfristige Soll-/Ist-Drehzahl/-Richtung. Eine Positionsbestimmung im Zimmer auf Basis der Encoderdaten ist meines Erachtens sinnfrei ;-) Ein kleinerer Motor (andere Bauart/Encoder auf Radachse) würde überschlagsmäßig reichen. Ich weiß noch nicht, für welchen ich mich entscheide.
Thomas Z. schrieb: > An einem Motor mit Getriebe befindet sich auf der Motorachse der > Drehgeber/Encoder. Durch das Getriebe ergeben sich auf der Abtriebsachse > 1.200 Steps pro Umdrehung. Häh?! Wo ist denn das Ding nun, auf der Motorachse oder auf der Abtriebsachse?
> Lt. Drehgeber-Artikel müsste ich also mit 200kHz abtasten. > Das ist zuviel. > Idee: einfach mit zwei Binär-Zählern die Signale durch 16 teilen Also 12500Hz wären ok ? Dann rechne doch einfach noch mal nach, 10000 Steps, 4 Zustände, macht 40000 Hz Abtastung, weit weniger als deine befürchteten 200000, und sollten doch "drin" sein. Natürlich kann man Incrementaldecoderauswertung auch in Hardware machen. http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
Thomas Z. schrieb: > Gute Frage. Wenn der Motor nicht gerade mit 500 U/min dreht, sollte sich ein Unsicherheitsfaktor von 4 mit ein paar Leuchtdioden (evtl. mit Treiber) an den Encoderausgängen doch ausräumen lassen. Und ob man jeden Step 20 mal abtasten muss, damit man ihn mitkriegt, sei jetzt mal dahingestellt. Für die richtige Dekodierung muss man jede Phase des AB-Signals genau ein Mal erwischen.
@Thomas Z. (tezet) >Einfach einen kleinen Roboter (Hobby/Entspannung). Es geht eher um >kurzfristige Soll-/Ist-Drehzahl/-Richtung. Eine Positionsbestimmung im >Zimmer auf Basis der Encoderdaten ist meines Erachtens sinnfrei ;-) Sag das nicht. Bring einen Zeiger am Getriebausgang an. Nun fahre wilde Muster, beschleuningen, bremsen, Richtungswechsel etc. Im Controller hast du die Position. Wenn an Ende der Zeiger wieder genau auf Null steht, ist deine Auswertung korrekt.
@ Marian B. (phiarc) >http://www.elektrik-trick.de/sminterf.htm >An /CLK noch einen ripple counter ran und fertig is. NEIN! Siehe Drehgeber !
hat dein geber einen referenzausgang? den könntest du bei hohen drezahlen verwenden und bei geringen drezahlen wieder auf die normaile auswertung wechseln.
Falk Brunner schrieb: > @ Marian B. (phiarc) > >>http://www.elektrik-trick.de/sminterf.htm > >>An /CLK noch einen ripple counter ran und fertig is. > > NEIN! Siehe Drehgeber ! Heh? Ja ich weiß was ein Drehgeber ist... mein Vorschlag war in Hardware ein Taktsignal aus AB abzuleiten und mit einem INT nur jede x-te Flanke zu erfassen. Damit würde die Auflösung um Faktor x reduziert... Allerdings müsste man AB wohl vorher noch in HW entprellen, ein Problem was man bei den Schrittmotörchen nicht hat...
du hast kein 1200*500 sondern 64*500 (der geber ist vor dem getriebe!!!) das sind nur noch 500 pulse pro sec, das schafft ein µC durchaus noch ohne große anstrengungen.
@Clemens S. (zoggl) >du hast kein 1200*500 sondern 64*500 (der geber ist vor dem getriebe!!!) Am Motor. >das sind nur noch 500 pulse pro sec, das schafft ein µC durchaus noch >ohne große anstrengungen. Nö, er hat schon 1200 Pulse / U am Getriebeausgang mit bis zu 500 U/min am Getiebeausgang.
Danke für die vielen Beiträge. Ein IC-Grab will ich ungern machen und Spezialchips sind auch nicht gut. Ich denke gerade darüber nach, einen Tiny zu nehmen, und die Signale von zwei Encodern in der Hauptschleife auszuwerten, korrekt runterzuteilen und Pins zu wackeln. Der Haupt-myC "denkt" das wären entsprechend langsame Encoder.
Eigentlich fällt mir zu diesem Problem nur eine einfach Hardware-Lösung ein die mit Hilfe einer CPLD gelöst wurde und 2-Quad-Decoder in Richtung/Schritt wandelt. Es ist dafür nur ein einfacher TTL-Oszillator mit um die 1-2Mhz und eine XC9536 nötig. Ob der TTL-Oszillator nun 1,8 oder 1Mhz hat, ist eigentlich egal. Bei 1Mhz Takt gehen auf jeden Fall 250Khz am Eingang. Bei schnelleren Signalen müsste man zunächst mal etwas am Eingang filtern. Man kann dass auch in HDL schreiben, ich habe jedoch darauf mangels Bedarf darauf verzichtet. Das Mapping der Funktionen zum Pin des Chips macht man am besten in einer Datei oder erzeugt sie in der ISE (Xilinx Der Dekoder ist kein Hexenwerk wie man sehen kann. Am Ausgang kommt der Takt und die Richtung an - der Takt geht in einen Counter-Eingang des AVR und mit dem Richtungsausgang an ein Portbit. Nun muss der Controller nur noch den IRQ für das Richtungsportbit bedienen und bei Änderung entweder vor- oder rückwärts zählen lassen. Ich habe in einer weiteren Version ein 32Bit Vorwärts/Rückwärts Zähler implementiert. Der wird einfach mit 8Bit breiten Leitungen zum Chip ausgelesen gesetzt rückgesetzt. Der lies sich jedoch nicht mehr im xc9536 (5V) synthetisieren und musste in einem XC9572XL (3.3V) umziehen. Die Schaltung kostete knapp €3.- gekostet und funktioniert bis ca. 170Mhz. http://www.mikrocontroller.net/part/XC9536 // ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++ // Modifiziert 04/2010 von G. Wesser, DD4DA zur Ausgabe der Ticks,Richtung // Ein zweiter Decoder wurde integriert -- mit je ein 4-Bit Zählregister // in dem XC9536 lassen sich keine zwei 8-Bit Zähler unterbringen // da zu wenige IOB's da sind. Ein XC9572 würde jedoch funktionieren. // vy 73 de DD4DA // ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++ // Initiated in 08/2009 and modified in 04/2010 by G. Wesser. // This Project build two Quad-Decoder (gray code) for decoding the A and B Signal // of an incremental encoder to Ticks and Direction of each Incremental encoder. // In addition, i add a 4 Bit binary counter for each decoder. This should gives a MCU // the posibility to use normal I/O Ports instead Tick and Direction. IT's also usable // as a prescaler 1/2, 1/4, 1/8 and 1/16 of the Ticks to get different resolutions. // Use one of them and the direction signal instead the TICK output. module quad(clk, quadA, quadB,quadC, quadD, count1, count2, richtung1, richtung2, ticks1,ticks2); input clk, quadA, quadB, quadC, quadD; output [3:0] count1; // Output Register ist 4 Bit breit output [3:0] count2; // Output Register ist 4 Bit breit output richtung1, ticks1, richtung2, ticks2; reg [2:0] quadA_delayed, quadB_delayed, quadC_delayed, quadD_delayed; always @(posedge clk) quadA_delayed <= {quadA_delayed[1:0], quadA}; always @(posedge clk) quadB_delayed <= {quadB_delayed[1:0], quadB}; always @(posedge clk) quadC_delayed <= {quadC_delayed[1:0], quadC}; always @(posedge clk) quadD_delayed <= {quadD_delayed[1:0], quadD}; wire count_enable1 = quadA_delayed[1] ^ quadA_delayed[2] ^ quadB_delayed[1] ^ quadB_delayed[2]; wire count_direction1 = quadA_delayed[1] ^ quadB_delayed[2]; wire count_enable2 = quadC_delayed[1] ^ quadC_delayed[2] ^ quadD_delayed[1] ^ quadD_delayed[2]; wire count_direction2 = quadC_delayed[1] ^ quadD_delayed[2]; reg [3:0] count1; // 4-Bit Zähler - kann ggf erweiter werden reg richtung1; // Richtung Rechts=Low Links=High reg ticks1; // Impulse für den Weg reg [3:0] count2; // 4-Bit Zähler - kann ggf erweiter werden reg richtung2; // Richtung Rechts=Low Links=High reg ticks2; // Impulse für den Weg // Erster Quad-Decoder always @(posedge clk) begin if(count_enable1) begin if (ticks1 == 1 ) ticks1 <= 0; else ticks1 <= 1; if (count_direction1) begin count1 <= count1 + 1; // Zähler um 1 erhöhen richtung1 <= 1; // Richtung ausgeben - High end else begin count1 <= count1 - 1; // Zähler um 1 mindern richtung1 <= 0; // Richtung ausgeben - LOW end end end // Second Quad-Decoder always @(posedge clk) begin if(count_enable2) begin if (ticks2 == 1 ) ticks2 <= 0; else ticks2 <= 1; if (count_direction2) begin count2 <= count2 + 1; // Zähler um 1 erhöhen richtung2 <= 1; // Richtung ausgeben - High end else begin count2 <= count2 - 1; // Zähler um 1 mindern richtung2 <= 0; // Richtung ausgeben - LOW end end end endmodule
Ja, genau sowas meine ich - nur in einem Tiny. Wenn ich im Haupt-myC zwei Timer/Counter frei habe, dann ist natürlich ein Takt/Richtungssignal sinnvoller als ein runtergeteiltes A/B-Signal.
Nur zur Info, da die Frage offen war, ob Flankenwechsel oder ganze Perioden in der Produktbeschreibung gemeint waren: Der Encoder hat 64 Flankenwechsel pro Umdrehung. Also sollte man mit 20kHz Abtastfrequenz hinkommen.
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.