29:1 Getriebe mit variabler Übersetzung?

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

......Bild hier  
in diesem Thema.

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

......Bild hier  

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.

......Bild hier  

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". Also Zustand der beiden Signalsbits zum Zeitpunkt t_-1 merken, mit Zustand zum Zeitpunkt t₀ 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.