29:1 Getriebe mit variabler Übersetzung?

[oberallgeier]

eigentlich "29:1 - oder darfs a bisserl mehr sein"
Seltsamer Thematitel, ich weiß.

Wieder mal etwas auf die Räder bringen hieß meine selbstgestellte Aufgabe. Also habe ich zwei baugleiche Getriebemotoren gekauft. Nun bin ich nicht ganz ungeübt eigene Encoder zu bauen, aber ich wollt mal was "Richtiges" haben - und ausserdem ne Drehrichtungserkennung. Die Auswahl war schnell getroffen, 350 Nenn-UpM und rund 0,8 Nm, dazu 12 V Betriebsspannung und max. 5A beim Blockieren waren Werte, die meine Vorstellungen gut abdeckten. Das ergab den
Getriebemotor 12VDC, Metallgetriebe 29:1, mit 64 CPR Encoder, (http://www.pololu.com/product/1443) 350rpm und ner 6mm Achse.

Erste Testläufe zeigten, dass die beiden Motoren deutlich unterschiedlich sind. Na ja, das kenne ich (spätestens von meinem MiniD0) , das bügelt die Regelung locker aus (bügle ICH mit ner sauberen Regelun...).

Die verkaufsfördernde Formulierung 64 CPR (count per revolution) hab ich notgedrungen geschluckt. Bei ner Drehrichtungserkennung sinds ja eher nur 32, eigentlich nur 16 : wenn ich das per Interrupt einlesen will nehme ich nämlich ne steigende Flanke an einem Kanal und schaue nach, welchen Pegel der andere Kanal hat. Nutze ich beide Flanken, muss ich in der ISR ne Fallunterscheidung für die Flankenform machen um die Drehrichtung zu erkennen ... und Zeit ist ISR-Pfiffigkeit. Und nutze ich alle Flanken - weil 64 CPR - dann sollte mir jemand garantieren, dass Spur A gegen Spur B um GENAU 1/4 Phase verschoben ist. Bei einer anderen Phasenverschiebung gäbe es nämlich mehr oder weniger leichte Regelungsunsauberkeiten.

Trotz des ganzen Wissens und der Überlegungen stimmte meine gemessene Drehzahl nicht.

Dauernd waren die gemessenen, angezeigten Drehzahlwerte (am Terminal) anders als die gerechneten und kontroll-gestoppten. Und nu? Da stelln wa uns mal jaants domm - - nutzte hier nix. Da drehn wa mal mit der Hand jenau eine Umdrehung. Hmmm. Mal jenau zehn ... hmmmmmmmmm. Hindrehen zehn - hmmmm-en, zurückdrehen zehn - genau auf die richtige Stellung bei Start und Ende achten - wieder die hmmmm´s. Anderer Motor.

Ich kanns drehn und wenden wie ich will. Statt 464 steigende Flanken pro Umdrehung der Abtriebswelle zeigen meine Messungen - egal ob eine oder zehn oder fünfzig Umdrehungen 480 CPR ± 2 .. 4, je nach Anzahl der Mess-Umdrehungen.

Das macht ziemlich sicher eine Untersetzung von 30:1. Ist ja nicht schlimm, sind ja nur drei Prozent, das wäre sogar bei ner Radarmessung am Auto noch die einzurechnende Toleranz. Aber ich will ja den Encoder nicht für eine schätzungsweise Regelung sondern für ne genaue; ich will die abgearbeiteten Drehungen für ne exakt gefahrene Strecke - Odometrie lässt grüßen - und - und - und. Da sind drei Prozent reichlich daneben. Was sagt das Angebot und das Datenblatt - Metallgetriebe. Sind das Gummizähne - ähhh - Reibräder, dass die Untersetzung irgendwo zwischen 29:1 und 30:1 liegen kann? Sind die Übersetzungsverhältnisse im think-metrik-but-more-inch-Country anders zu rechnen als im komischen alten Europa?

Das Gute: beide Motoren haben die gleiche Untersetzung.

Frage: wer hat die gleichen Motoren - UND hat schon mal die Übersetzung genau ausgemessen? Weiß jemand etwas von ner Typänderung?

Ich werde vielleicht mal die Leute von pololu fragen, die sind eigenlich ziemlich firm. Das muss ich doch klären.

[Manf]

So kann eine Messung der Übersetzung aussehen:
Zerlegen, fotografieren auszählen.
Bei diesem recht guten kleinen Motor habe ich mich noch gewundert, dass die Zähnezahl meist geradzahlig ist.
Oft werden ja zur besseren Verteilung der Schmierung die Verhältnisse gepaarter Zahnräder so gewählt dass alle Zähne mal zusammenkommen. Das Übersetzungsverhältnis ist dann etwa so anschaulich wie "29,876543" und wird eher als Näherung angegeben.

27157

(Nur als Anmerkung, ich bin mir nicht sicher, ob das genau das Problem ist.)

[oberallgeier]

... Messung der Übersetzung aussehen ... Zerlegen, fotografieren auszählen ...NOCH bin ich da zurückhaltend. Mal sehen, was die Leute aus NV meinen. Die schraubenziehergestützte Messung kenn ich ja schon hier z.B.

......https://www.roboternetz.de/community/attachment.php?attachmentid=31454&d=1458723539
in diesem Thema. (https://www.roboternetz.de/community/threads/32293-DC-Kleinstmotor-mit-Getriebe-Drehsensor-5V-510-Upm?p=395659&viewfull=1#post395659)

Grund für das Dilemma könnte natürlich eine unkonventionelle Rundung beim Berechnen der Untersetzung sein. Dass der Grund ein Getriebe mit einem oder mehreren primzahligen Rädern oder so was Ähnlichem wäre, kann ich mir dagegen kaum vorstellen. Die "30:1" ist wohl ne ziemlich genaue Angabe (aber tausend törns hab ich noch nicht gemessen *gg*). Danke jedenfalls für den Denkanstoß.

[ranke]

Ich kanns drehn und wenden wie ich will. Statt 464 steigende Flanken pro Umdrehung der Abtriebswelle zeigen meine Messungen - egal ob eine oder zehn oder fünfzig Umdrehungen 480 CPR ± 2 .. 4, je nach Anzahl der Mess-Umdrehungen.

Das macht ziemlich sicher eine Untersetzung von 30:1.

Alternativ (selbes Symptom) wären 66 statt 64 gemessene Encoderimpulse pro Motorumdrehung bei korrekter mechanischer Untersetzung. Das scheint zwar auf Anhieb auch nicht wahrscheinlich, kann man aber mal im Hinterkopf behalten, falls die Suche in der Richtung Getriebe nicht weiterführt.

[oberallgeier]

Alternativ (selbes Symptom) wären 66 statt 64 gemessene Encoderimpulse ...Ja? Also 464/16 wären 29,00000 und 480/30 genau 16. ABER 66 lässt sich garnicht vierteln

......http://a.pololu-files.com/picture/0J2643.200.jpg?45333fd98b7b01d1a4a7c52dd70550b6

das müssten dann 68 sein . . . denn jede Spuren bringt eine gerade Anzahl von Ticks - also Vielfache von Zwei. Beide Spuren bringen dann - da sie bestimmt(hoffentlich*gg*) gleiche Teilung haben - auf alle Fälle ein Vielfaches von vier.

Aber ist nicht so. Ich habe gerade einen Strich am Encoderrädchen gemacht. Das und der Hallsensor liegen frei am Heck des Motors.

......http://b.pololu-files.com/picture/0J4045.200.jpg?13afa9c13644b8dc131efd8f512261e1

Dann den Encoder und damit die Motorwelle genau 30 Umdrehungen gedreht und siehe da - die Abtriebswelle stand genau da, wo sie vorher auch stand. Ganz ohne elektronische Datenabfrage bzw. -ausgabe. Zerstörungsfreie und montagelose Prüfmethode (so richtig für faule Leute wie mich).

Wie oben erwähnt, mal warten, was die Leute in Nevada dazu meinen.

[HeXPloreR]

Exakt das gleiche Problem hab ich bei einem selbstgebauten Liniearantrieb festgestellt. Dazu habe ich einem RS-2 Servo eine Encoderscheibe spendiert. Jetzt fahre ich die Zahnstange 200 ticks hin und her ...und sie verschiebt sich bei jedem mal rausfahren um 2 bis 5 ticks - das bedeutet die Stange fällt nach einiger Zeit hin und her bewegen einfach auf der einen Seite raus. Die Getriebeuntersetzung ist vermutlich höher als bei Deinen Motoren und daher ist der Fehler bei Dir möglicherweis auch kleiner.

Bisher liegt meine Fehlervermutung im Umkehrspiel des Getriebes. Allerdinsg hab ich das Projekt erstmal zur Seite gelegt weil ich wichtigere Dinge erledigen möchte.

[RoboHolIC]

fahre ich die Zahnstange 200 ticks hin und her ...und sie verschiebt sich bei jedem mal rausfahren um 2 bis 5 ticks ... Bisher liegt meine Fehlervermutung im Umkehrspiel des Getriebes
Ziemlich sicher Nein. Umkehrspiel ist Spiel in der Verzahnung, kein Überspringen ("Drüber-ratschen") von Zähnen.
Die Verschiebung rührt ganz sicher von einer fehlerhaften, gestörten oder übertakteten Inkrementalgeberauswertung.

[malthy]

Hallo oberallgeier,

ich weiß, es geht ein wenig an Deiner eigentlichen Frage vorbei ...


Die verkaufsfördernde Formulierung 64 CPR (count per revolution) hab ich notgedrungen geschluckt. Bei ner Drehrichtungserkennung sinds ja eher nur 32, eigentlich nur 16 : wenn ich das per Interrupt einlesen will nehme ich nämlich ne steigende Flanke an einem Kanal und schaue nach, welchen Pegel der andere Kanal hat. Nutze ich beide Flanken, muss ich in der ISR ne Fallunterscheidung für die Flankenform machen um die Drehrichtung zu erkennen ... und Zeit ist ISR-Pfiffigkeit. Und nutze ich alle Flanken - weil 64 CPR - dann sollte mir jemand garantieren, dass Spur A gegen Spur B um GENAU 1/4 Phase verschoben ist. Bei einer anderen Phasenverschiebung gäbe es nämlich mehr oder weniger leichte Regelungsunsauberkeiten.

Dein Encoder gibt doch ganz offensichtlich ein normales Quadratursignal aus, warum wertest Du das nicht so aus, "wie man es normalerweise macht (http://www.mikrocontroller.net/articles/Drehgeber)". Also Zustand der beiden Signalsbits zum Zeitpunkt t-1 merken, mit Zustand zum Zeitpunkt t0 vergleichen und daraus dann Schritt und Schrittrichtung bestimmen. Dann kommst Du auf die vollen 64 Schritte Auflösung.

Gruß
Malte

[oberallgeier]

... warum wertest Du das nicht so aus, "wie man es normalerweise macht" ...Danke Malte für den Hinweis. Warum ... nicht: ich hab den Code schnell hingeschrieben und trotz der Warnung bei mikrocontroller-net momentan an den externen Interrupt gehängt. Damit habe ich vorerst gute Ergebnisse bei der Sprungantwort. Das Beispiel bei mikrocontroller-net habe ich überflogen aber (noch) nicht verstanden *gg*. Kommt noch, ich bin meist lernfähig. Trotzdem habe ich erstmal das Gefühl, dass die volle Auflösung nicht darauf bauen kann, dass alle Flanken gleiche Abstände haben - - - das ist ja auch EIN Grund für einschrittige Codes. Wie genau/reproduzierbar der Sensor bzw. die einzelnen Teilstücke wirklich ist/sind, kann ich auch noch nicht sagen.

Ein vorrangiges Thema war für mich die Unklarheit bei der Untersetzung.

[malthy]

Ich habe bisher nur mit magnetischen Encodern gearbeitet (die allerdings viel höhere Auflösungen haben) und für die ist es so wie Du sagst: das Quadratursignal ist z. T. erheblich asymmetrisch, also die Phasenverschiebung zwischen den Teilsignalen ist durchaus nicht konstant 90° sondern variiert. Aber Dein Argument (soweit ich Dich richtig verstanden habe) sehe ich trotzdem nicht ganz ein. Du verzichtest auf eine vierfach höhere Auflösung, weil Du bei dem (dann viermal kleineren!) Inkrement einen gewissen Fehler erwartest?

Das Problem bei der Auswertung mit PCINTs ist ja nur, dass das potentielle Prellen des Encoders den µC ausbremsen kann. Bei den o. g. magnetischen Encodern habe ich Prellen nie beobachtet, insofern hat die Auswertung über pin change interrupts auch immer gut funktioniert (aus Ehrfurcht vor den mc.net Profis mache ich es trotzdem meist über einen Timer Interrupt ;-)). Ich könnte mir vorstellen, dass insb. mechanische Encoder zum Prellen neigen, der an deinem Motor wird eher ein optischer sein, oder? Da würde man ja auch eine gewisse Signalnachbereitung erwarten, die zu eine Hysterese führt ... Just my two cents.

Gruß
Malte

P.S.: wie gesagt, ich weiß dass das nicht Dein vorrangiges Problem war, mir fiel es nur auf ...

[oberallgeier]

... verzichtest auf eine vierfach höhere Auflösung ... das potentielle Prellen ... habe ich Prellen nie beobachtet ... nicht Dein vorrangiges Problem war ...Malthe, GENAU DAS ist ja das Gute hier im Forum, dass manchmal auch ein Beitrag kommt nach dem Motto "... mir fiel es nur auf".

Im Übrigen:
a) erstmal keine höhere Auflösung weil ich NACH Vorliegen der Sprungantworten
....die Dynamik des Systems besser kenne und erst danach
....die für mich optimale Auflösung wählen kann -
....- im Rahmen der Möglichkeiten.
b) siehe weiter unten (Antiprell..)
c) meine Bussole meint das es ein magnetischer Encoder ist
d) Prellen kenne ich in meinen Projekten praktisch garnicht,
....weder bei Tasten, auch nicht hier,
....habe trotzdem ne kleine Prell-Abwehr eingebaut, siehe unten und b)


... Just my two cents ...Anyway, a lot of know how *gg*

Mein Antiprelludin:

ISR(INT0_vect) // INT0 triggert auf RISING edge =>
{ //
if (tmrE0 <= 2 ) return; // Bei zu kurzen Zeiten gleich return
Iz_diff0 = tmrE0; // Abspeichern Zeit seit dem letzten ISR-Aufruf



Von Derrill Hartley Mi, 15.Jan.2014 um 1:26
Re: What´s wrong with my pololu 29:1 Metal Gearmotor
Hello.
Thank you for your interest in our gearmotors. Our manufacturer for those motors changed the specifications without telling us about it. We are aware of the problem and are currently testing the motors and updating the website. We have also arranged with our supplier to inform us of any future changes.
For that motor we have confirmed that it is a 30:1 gear ratio as you figured out. We are sorry for any confusion this might have caused.
Please let me know if you have any additional questions.
Sincerely,
Derrill Hartley
(702) 262-6648
www.pololu.com
..............................
Pololu Corporation
920 Pilot Rd.
Las Vegas, NV 89119
USA
- - - - - - - - - - - - - - - - - x - - - - - - - - - - - - - - -
What´s wrong with my pololu 29:1 Metal Gearmotor Di, 14.Jan.2014 um 15:20
... So, for my new project I bought two of your
29:1 Metal Gearmotor 37Dx52L mm with 64 CPR Encoder, item #: 1443
from your german associate EXP Tech Meerwiesertalweg 23 D-66123 Saarbrücken. The high torque, speed sensor etc - fits really good with my target specifications.

The question (and not really problem for me) is the reduction gear ratio from this part. You specify 29:1 - - but, please check it, maybe it´s different.

My test installation (after some trouble - because the measured speed did´nt suit with my calculations based of the 29:1-value, so neiter the closed loop system nor the odometry will run exactly) :
- white line (marker) on the encoder wheel
- line on the mounting hub (item #: 1083) on the gearbox output shaft

... and then softly turning the encoder wheel. After 30 (!!) revolutions of the encoder wheel the line on the mounting hub on the gearbox output shaft reaches the exact position then bevor. 30 revolutions - not 29!

Na ja, dem "Our manufacturer ... changed the specifications" ist ja kaum mehr zuzufügen als - Eingangskontrolle >on site< kann vor Problemen bewahren. Und wenn schon nicht Eingangskontrolle, dann zumindest ein gutes Arbeitsheft ...

[WL]

Wir haben mal ein Präzisionsgetriebe 1:10 (um die Impulse eines Inkrementalgebers zu vervielfachen für eine Synchronregelung)
aus dem Lager gewechselt und anschließend lief die Maschine nicht mehr venünftig.:confused:

Nach dem Zerlegen und analysieren stellte sich heraus das ein Träumer beim Montieren ein falsches Zahnradpaar eingesetzt hat.
Das Getriebe hatte dann glaube ich eine Übersetzung von 1:9,85312 oder so ähnlich (lt. Typenschild aber 1:10).

Ein weiteres passte dann wieder.

....so ist das halt in der hoch technisierten modernen Welt............

[oberallgeier]

... Präzisionsgetriebe 1:10 ... ein falsches Zahnradpaar eingesetzt ... 1:9,85312 ...Hmmm. 1,5% Fehler bei der Übersetzung!? Mit einem falschen Zahnradpaar - das müsste auch den richtigen, passenden Achsabstand gehabt haben . . . hmmmmm.

[malthy]

Nach dem Zerlegen und analysieren stellte sich heraus das ein Träumer beim Montieren ein falsches Zahnradpaar eingesetzt hat.
Das Getriebe hatte dann glaube ich eine Übersetzung von 1:9,85312 oder so ähnlich (lt. Typenschild aber 1:10).

Manf hatte weiter oben ja schon folgende Anmerkung gemacht:


Oft werden ja zur besseren Verteilung der Schmierung die Verhältnisse gepaarter Zahnräder so gewählt dass alle Zähne mal zusammenkommen. Das Übersetzungsverhältnis ist dann etwa so anschaulich wie "29,876543" und wird eher als Näherung angegeben

Vielleicht war es eher das? Kommt mir nämlich auch eher seltsam vor, dass ein hochwertiges Getriebe einfach so "mit einem falschen Zahnradpaar" zu bestücken ist ... :-)

[WL]

. . . hmmmmm.


auch eher seltsam vor, dass ein hochwertiges Getriebe einfach so "mit einem falschen Zahnradpaar" zu bestücken ist .

Bei der Aktion habe ich auch nur ungläubige Gesichter gesehen.......... ;)

Nach dem Auszählen der (vielen) Zähne lagen die Fakten auf dem Tisch.

[malthy]

Nach dem Auszählen der (vielen) Zähne lagen die Fakten auf dem Tisch.

Die Fakten betstreitet ja auch niemand. Die Frage ist nur, ob die krumme Untersetzung ein Versehen oder Absicht war :-). Aber jetzt wollen wir oberallgeiers Thread lieber nicht zu weit ins off-topic treiben ...

Gruß
Malte

[oberallgeier]

Die beiden Getriebemotore machen ansonsten alles richtig. Keine irritierenden Spikes beim Flankenwechsel (Antiprellzeilen - s.oben - entfernt) , die Leerlaufdrehzahl ist etwas über den techn. Daten. Die Beschleunigung ist wohl baugrößengerecht.

.....


... Nach dem Auszählen der (vielen) Zähne lagen die Fakten auf dem Tisch.Ich hätte eher geraten, dass nach dem Auszählen der vielen Zähne auf dem Tisch die Fakten klar lagen.

[oberallgeier]

Die beiden Getriebemotore machen ansonsten alles richtig ..Sorry für die späte Antwort. Ich hatte kurz nach dem vorigen Post pololu auf die Diskrepanz hingewiesen (wieder einmal). Die hatten es mit möglichen, nicht rückgemeldeten Änderungen beim Lieferanten begründet. Mittlerweile steht die richtige Übersetzung im Datenblatt.