Speisung HAT und Schrittmotor

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo

    Ich bin bin Einen Kameraslider am entwerfen. Hierzu Bräuchte ich aber Hilfe bei der Stromversorgung des Schrittmotors Nema 17, den ich dazu verwenden will.
    Als Controller habe ich den http://www.play-zone.ch/de/adafruit-dc…i-mini-kit.html.

    Laut Datenblatt braucht der Motor ja 4.16V.
    Die Stromversorgung des HAT kann ja zwischen 4.5V-13.5V sein.

    Frage: Wird die angelegte Spannung 1:1 an den Schrittmotor weitergegeben?
    In den gefundenen Beispielprogrammzeilen sehe ich nirgends, das dies irgendwo als Parameter auftaucht.

    Wenn ich diesen 6V Batteriehalter zur Stromversorgung nehme würde das gehen?
    Was passiert, wenn ich jetzt einen 12V Halter nehme? Brate ich damit dann den Stepper oder regelt der HAT das ganze dann herunter?


    Vielen Dank schon im Voraus für Eure Hilfe.

  • Du kannst einen Schrittmotor problemlos auch mit höheren Spannungen betreiben, wichtig ist dabei, dass der Strom begrenzt wirt. Das geht über die meisten Schrittmotor Treiber. Dein Motor hätte gern pro Phase 1,3 A bei 4,16V - also 5,41 Watt. Willst du ihn mit 6v betreiben versucht der Motor trotzdem 1,3 A zu ziehen und würde damit 7,8 Watt pro Phase tilgen, was ihn heiss werden lässt.

    Du müsstest also über den Treiber auf 1,1 A reduzieren.... grob gesagt - der Strom darf den angegebenen maximalwert nicht übersteigen - die Spannung die angegeben wird bedeutet nur, dass bei dieser Spannung der Motor ohne Begrenzung des Stroms betrieben werden kann. Du kannst auch 12V anlegen, solange der Strom stimmt, macht das der Schrittmotor mit.


  • Du kannst einen Schrittmotor problemlos auch mit höheren Spannungen betreiben, wichtig ist dabei, dass der Strom begrenzt wirt. Das geht über die meisten Schrittmotor Treiber. Dein Motor hätte gern pro Phase 1,3 A bei 4,16V - also 5,41 Watt. Willst du ihn mit 6v betreiben versucht der Motor trotzdem 1,3 A zu ziehen und würde damit 7,8 Watt pro Phase tilgen, was ihn heiss werden lässt.

    Du müsstest also über den Treiber auf 1,1 A reduzieren.... grob gesagt - der Strom darf den angegebenen maximalwert nicht übersteigen - die Spannung die angegeben wird bedeutet nur, dass bei dieser Spannung der Motor ohne Begrenzung des Stroms betrieben werden kann. Du kannst auch 12V anlegen, solange der Strom stimmt, macht das der Schrittmotor mit.

    Guten Morgen und vielen Dank für die Hilfe.
    Unterdessen ist meine Bestellung angekommen. Also mit 6v läufts ganz okay. Mit 12 keine grosse Änderung, nur das der Motor wärmer wird. Habe jetzt ja noch gesehen, das das 1.2A pro Phase hat. Daher sollte das ja eigentlich doch gut gehen?

    Noch eine allgemeine Elektrofrage zum ganzen. Wenn ich den Kameraslider von hand bewege, dann erzeuge ich ja induktivstrom zurück auf den Motorentreiber. Muss ich dann entweder mechanisch entkuppeln, oder eine Sperrdiode einbauen oder ist das Motorshield schon geschützt? Ich habe gesehen, dass die PowerLED anfängt zu leuchten, sobald ich den Motor nur ein bisschen von hand drehe.

  • Hallo

    Unterdessen habe ich alles zusammengebaut und bin am testen.
    Mir ist aufgefallen, dass ich in eine Richtung genug Drehmoment habe, aber in der anderen Drehrichtung rutscht der Motor beim geringsten Widerstand durch.
    Ich verwende diesen Schrittmotor: http://www.play-zone.ch/de/elektronik-…4mm-schaft.html und diesen Motorentreiber http://www.play-zone.ch/de/adafruit-dc…i-mini-kit.html. Ich habe die Klassen von der Adafruit homepage verwendet um den Motor anzustuern. Es ist dabei egal, ob ich mit Single, Double, Interleave oder Microsteps fahre.
    Gespiesen wird der HAT bzw. die Motoren mit 4x AA Akkus (also 4.8v).

    Hat dazu jemand eine Erklärung, bzw. was ich vlt. falsch mache? Ich vermute, das der Motorentreiber evtl. nicht so toll ist. Würde hier evtl. einer dieser Motorentreiber besser funktionieren? http://mechadroid.aaac.ch/Elektronik/Mot…rrier::212.html , da ich bei diesem dann auch mit höherer Spannung und Strombegrenzung arbeiten kann?

  • Hi,

    bei meinen Versuchen mit dem Adafruit DC & Stepper Motor HAT und diesem 12V Stepper Motor habe ich ganz ähnliche Erfahrungen machen müssen. Die Ansteuerung über den HAT klappt Problemlos (der HAT wird bei mir über 12V versorgt), nur ist es ziemlich egal welches der Beispielskripte von Adafruit man verwendet, der Stepper 'vergisst' manchmal einfach einen Schritt und 'ruckelt' (gerade beim beschleunigen bzw. abbremsen) dann merklich.

    Auch hat mir die Haltekraft des Steppers von 2 Kg zunächst gut in den Kram gepasst - dann musste ich aber feststellen, dass der Motor (wie bei Steppern üblich, hinterher ist man schlauer) diese nur im Stillstand und mit dem entsprechenden Stromverbrauch plus der dazugehörigen Wärmeentwicklung bringen kann und die Haltekraft im Betrieb (er soll einen Schlitten auf einem Slider bewegen und halten, auf dem ein Remote Head verbaut ist, ca. die benannten 2 Kg mit DSLR) dann massiv zusammenbricht.

    Da mein Slider auch vertikale Fahrten ermöglichen soll ist es mir wichtig, dass der Motor den Schlitten mit Head sicher halten kann (klar, dieser Motor ist dafür unterdimensioniert, aber er wurde auch nur zum testen ohne den Head genutzt, also nur ca. 800 Gr) habe ich die Idee mit einem Stepper Motor zu arbeiten komplett in die Tonne getreten.

    Inzwischen bin ich zu einem 12V Getriebemotor umgeschwenkt, der eine Haltekraft von 14 Kg mitbringt und - das ist am Ende der wichtigste Punkt - über ein selbstsperrendes Getriebe verfügt. Letzteres bedeutet, dass der Schlitten mit Remote Head auch in der Vertikalen sicher steht und ich mir keine Gedanken über den für diese Haltekraft notwendigen Strom machen muss.

    Es mag ja sein, dass ein Stepper auch toll funktionieren kann (vor allem weil er reproduzierbare Schrittfolgen liefern kann) aber in der Summe hat er für mich mehr Nach- als Vorteile. Der nächste Versuch wird einer mit einem anderen DC Getriebemotor, der einen Drehencoder verbaut hat. Letzterer kann pro Umdrehung der Motor Achse bis zu 64 Schritte auflösen - was bei einer 200:1 Untersetzung dann sage und schreibe 12800 Schritten entsprechen sollte. Damit hoffe ich beide Vorteile vereinen zu können :)

    Zum A4988 Treiber kann ich dir leider nichts sagen, ich arbeite nach wie vor mit dem Adafruit HAT und habe die 12V DC Motoren mit ner 2A Feinsicherung angekabelt um den HAT nicht zu schrotten (3A bei maximum Stall überlebt der Adafruit HAT nicht, der hat nur max. 3A Peak).

  • Hallo "doing"

    Vielen Dank für die Antwort. Es tut gut zu lesen, das jemand ähnliche Erfahrungen gemacht hat.
    Ich bin ja noch in der Experimentierphase. Ein 3kg Gewicht in einem ca. 20° Winkel schafft er gerade noch, bei meiner DSLR.
    Also auch Ballhead und ein entsprechendes Objektiv. 17-200mm bei f2 =). Gewogen habe ichs noch nicht aber geschätzt so 3kg.

    Ja ich befürchte auch, das ich irgendwann zu einem Motor mit Getriebe wechseln muss. Gerade die Selbsthaltung wird von Vorteil sein, da dann kein Strom für das Halten gebraucht wird.
    Ich muss noch schauen, wie ich das am besten mache. Ich habe zwar Mechaniker gelernt, habe aber kein Bastelraum, fast keine Werkzeuge und nur eine 1 Zimmer Wohnung. Mit Fräsen und Drehen ist da nicht viel zu machen und auch keine Werkstatt in Reichweite. Ich habe übrigens diesen Kit genommen https://www.servocity.com/html/igus_w16_…ml#.VmsJiITtKFC. Sieht einfach top aus, gerade weil ich mit meinen begrenzten Möglichkeiten nur ein Gebastel zustande gebracht hätte. Mal schauen, was ich da für Möglichkeiten habe, etwas mit einem Getriebe zu machen.

    Ich hatte mal diesen im Sinn zu kaufen http://de.nanotec.com/fileadmin/file…icht_GPLE40.pdf habe mich aber dann dazu entschieden, erst mal nur den Stepper zu kaufen. Vielleicht geht ja diese Kombination mit dem Stepper und dem Getriebe. Muss noch heraussuchen, ob mit diesem Getriebe das ganze dann selber gehalten wird. Ansonsten wahrscheinlich eine höhere Untersetzung wählen.

    p.s. Ich habe gemerkt, das der HAT nur etwa 60RPM bring. Wenn ich höhere Werte vorgebe, passiert nicht viel mehr. Ist das bei Dir auch so?

    p.p.s. Die Variante mit DC Motor und Encoder müsste ich mir noch genauer anschauen, aber das ist mir im Moment noch ein bisschen zu kompliziert. Ich verstehe zwar das Prinzip so in etwa, aber wüsste noch nicht, wie umsetzen. Denke aber eher, das ich das mit dem Stepper + Getriebe machen werde.

  • Hi Miracuru,

    wenn du schon bei Servocity unterwegs bist, dann schau dir doch auch mal die dort verlinken DC Getriebemotoren an. Die sind ziemlich ähnlich zu denen, die ich hier im Moment verwende (offenbar gleiches Getriebe, aber anderer Motor). Das IGUS eine Deutsche Firma ist weißt du? Die haben einen klasse Support (von denen kommt meine Energiekette) und bieten auch alle möglichen Sliderteile (deine Schiene, Gleitlager etc.) separat an.

    Getriebemotoren mit Drehencoder findest du z.B. bei Pololu > hier

    Bezüglich der maximalen Drehzahl hast du Recht, ich komme auch nicht auf mehr Umdrehungen mit einem Stepper. Auch daher habe ich den Schwenk zum DC Getriebemotor vollzogen - ich habe inzwischen verschiedene am Start, von 15 rpm über 30 rpm, 60 rpm und 100 rpm bis hin zu 200 rpm hinter dem Getriebe. Dazu habe ich mir eine Halterung einfallen lassen, die es ermöglicht den Motor für den Slider je nach Anforderung wechseln zu können.

    Mit 200 rpm und 1:2 GT2 Pulley Übersetzung fährt er die 1,5m Strecke in 3 Sekunden (inkl. beschleunigen und abbremsen). OK, Letzteres scheitert noch ab und an, aber ich habe Endschalter verbaut die dann einen 'Notstopp' auslösen... :D

    Einmal editiert, zuletzt von doing (11. Dezember 2015 um 19:23)

  • Ja cool

    Okay den anderen Treiber habe ich bereits erstellt. Ich denke, ich mach das so... Mal gucken, wie's mit dem polulu Motorentreiber läuft, evtl. mach ich dann auch den Schwenk zum DC Motor, wie Du :D.
    Da experimentiere ich gerne. Danke für die Links. Oh ich dachte, igus sei eine CH Firma. Wurden die evtl. aufgekauft? Ja bin echt zufrieden mit der Sliderschine.

    Okay die Geschwindigkeit ist denke ich eh Zweitrangig, wenn ich dann draussen bin um 'timelapse' Aufnahmen zu machen, dauert das eh Stunden.
    Ich habe das auch mit einem Magnetendschalter gemacht. Auf dem Display habe ich ein Menusystem (irgendwo heruntergeladen und modifiziert). Damit kann ich dann Verschiedene Funktionen auswählen und parameter ändern. Auch die Hintergrundbeleuchtung ist toll. Da habe ich im Moment rot, wenn noch nicht initialisiert (Nullpunkt Magenetschalter nicht angefahren). Grün, wenn initialisiert, Gelb, wenn im "Parameter ändern Modus", Blau bei aktivem Move-Shoot-Move Modus. Der Drehencoder habe ich noch dazu verbaut, um Parameterwerte zu ändern. z.b. Wartezeit, Schrittlänge, Geschwindigkeit etc.

    Hab mal ein Bild von meinem Entwurfgebastel hinzugefügt. wenn dann alles richtig funktioniert, dann Verbaue ich das ganze in ein richtiges Gehäuse und verwende einen richtigen Print anstatt die Experimentierplatte etc.

    Ahja, beim Bestellen muss ich noch ein bisschen mehr schauen, ob ich das nicht lokal bei einem reseller bestellen kann. Zum Glück habe ich da schon was gefunden, aber die haben jeweils nicht das ganze polulu oder servocity sortiment. Aber da kann ich noch über einen DE shop ausweichen und evtl. an grenzpaket.ch liefern lassen etc. :thumbs1:. Bei der Bestellung bei servocity bin habe ich nicht bedacht, das da noch 35CHF Zollgebühren anfallen :s. Ich muss aber schon sagen, macht echt Spass, damit zu experimentieren.

    Ahja blöde Frage, gell du verwendest auch einen Raspberry? Müsste ja so sein. Ich glaube auf einen Arduino funktioniert dieser Motor HAT nicht. Ich bin mir eben am Überlegen, das ganze dann später mal auf einem Arduino umzusetzen, da vielleicht etwas sicherer, wenn unterwegs. Wenn ich dann unterwegs mal einen Stromausfall habe, (warum auch immer) etc. reagiert der RPI ja mehr als ein Arduino, bezüglich sauber herunterfahren etc. Dem Arduino wird sowas ja relativ egal sein, da der nicht noch ein Betriebssystem im Hintergrund hat. Mal gucken.

  • Hättest du eine Canon vorgezeigt, hätte ich jetzt 'Schluss gemacht' ... ich vermute ja die Canons kaufen immer nur Fertiges, die Nikons fummeln > klasse Bild!

    Ja sicher, ich nutze einen Raspberry Pi 2B mit einer (ich mag es kaum tippen) Pi USV+ und einem kapazitiven 2.8'' Touch Display von Adafruit (oder es wird das offizielle 7'' Display, ich habe mich noch nicht endgültig entschieden - das offizielle ist etwas groß für einen Handheld Controller) für die Steuerung. Da der Remote Head ja keine Kabel an der Nikon gebrauchen kann werde ich dort einen 443 MHz Funkempfänger auf den Blitzschuh stecken (oder aber an den Head montieren), der von einem TinyDuino mit Kopfzelle versorgt wird und den Focus/Auslöser meiner Nikon triggert. Mit nem Arduino Nano funktioniert der Auslöser bereits - die TinyDuinos erwarte ich erst noch, da geht es mir nur noch um Miniaturisierung.

    Fotos werde ich nachreichen, keine Frage - wobei ich einen ganz anderen Ansatz Verfolge als du - ich baue auf den V-Slot Profilen von Openbuilds auf.

    Einmal editiert, zuletzt von doing (11. Dezember 2015 um 20:54)

  • Ja den "Schnappschuss" habe ich mit meinem Handy gemacht. Da habe ich auch gebastelt. Wenn ich genauer nachgelesen hätte, das beim rooten eines Sony Xperia Z3 die DRM keys unwiderruflich verloren gehen dann [...] Naja mit einem Workaround funktioniert alles wieder. Die DRM Keys werden unter anderem für die Rauschreduzierung gebraucht.

    Hmja seit ich zu früheren Zeiten mit der Powershot G7 einen Fehlgriff gemacht habe, bin ich zu Nikon gewechselt und habe so mit den DSLR angefangen.
    Bis jetzt bereue ich das nicht und es ist ein ganz anderes Photographieren.

    Das schaut ja klasse aus, mit dem TinyDuino.
    So einen remote head wollte ich auch schon lange. Aber ich brauch es nicht zwingend. So habe ich mich für die Kabellösung entschieden. Habe da einen einfachen Hama Auslöser genommen, damit ich den Anschluss an die Kamera habe und lasse den RPI mit diesem via Optokoppler auslösen, damit die beiden Stromkreise getrennt sind.
    Ich mache dann mal noch bessere Bilder und Beschreibungen dazu.

    Die V-Slot Profile von Openbuilds schauen ja auch fein aus.

    Etwas offtopic: Was ich schade finde, ist das Nikon keine GPS Empfänger in die DSLRs einbaut (Meine ist eine D7200). Jedesmal das Kabelgefummel für das Aufsteck GPS Modul.
    Etwas offtopic2: Wenn ich noch fragen darf. Machst du mit deinem System auch "Zeitraffer Aufnahmen" oder eher andere Anwendungen. Weil, ich fange damit erst an und bräuchte noch einen Tipp. So wie ich gelesen habe, sollte man, wenn man am Tag Photographiert noch einen Filter verwenden, um längere Belichtungszeiten zu erhalten, damit im fertigen Video nicht alles als "Stakkato" abläuft. Kennst du dich damit aus, und wenn ja, weisst du, was etwa eine gute Stärke des Filters wäre um anzufangen? Okay es gäbe noch die "einstellbaren" aber da weiss ich noch nicht so recht, ob das nicht zu verlustbehaftet ist, von der Qualität her.

  • Hi Miracuru,

    du hast ja immerhin die D7200 am Start, die hat wenigstens schon Wifi verbaut, das ist bei meiner D7100 noch nicht der Fall. GPS in die Kamera zu integrieren wäre eine gute Idee, aber dann würde Nikon ja keine von diesen Aufsteckmodulen mehr verkaufen...

    Um eine längere Belichtungszeit bei offener Blende realisieren und damit den 'Stakkato Effekt' zu minimieren solltest du dir mal ND (Neutraldichte) Filter ansehen. Damit lässt du (z.B. in der Mittagssonne) weniger Licht ins Objektiv und hast eine offene Blende mit einer schönen Tiefenunschärfe, die du ohne ND Filter nicht hättest. Schau dich mal bei Enjoyyourcamera um, die haben eine große Auswahl und vernünftige Preise in verschiedenen Qualitätsstufen. Wenn dich das herumgeschraube beim Filterwechsel nicht nervt kannst du dir einen Satz ND Filter kaufen, ansonsten nimm einen Vario Filter (z.B. mit ND2 - ND400, damit kommt 1/2 bis 1/400 des ursprünglichen Lichts in das Objektiv und du hast eine Verschiebung um 2 bis 8 Blendenstufen).

  • Danke noch für die Tipps zu den ND Filtern.

    Unterdessen bin ich tatsächlich bei den DC Motoren mit encoder + Getriebe angelangt, auch gerade wegen der Selbsthemmung.
    Der Polulu Treiber funktioniert übrigens ziemlich gut.

    Was ich noch nicht kapiere ist, ob die Rückmeldungen vom encoder direkt am RPI ausgewertet werden können.
    Ich habe mir diesen Motor angeschaut: https://www.pololu.com/product/2826.

    Beschreibung bei Polulu

    Zitat

    This gearmotor is a powerful 12V brushed DC motor with a 102.083:1 metal gearbox and an integrated quadrature encoder that provides a resolution of 64 counts per revolution of the motor shaft, which corresponds to 6533 counts per revolution of the gearbox’s output shaft.

    Max RPM @ 12V = 100 RPM am Motorschaft.
    Ich weiss jetzt nicht, wie ich rechnen muss.
    11'000rpm x 64counts = 704000 counts per minute = 11'733.33 counts per second (=11.73kHz)
    102.083pm x 6533counts = 666908.239 counts per minute = 11'115.14 counts per second (=11.12kHz)

    Wenn ich dann vom RPI Impulse von ca. 11kHz auswerten muss, denke ich, das ich da Probleme bekomme, wenn irgendwo die die Auslastung des RPI steigt, so dass das python Progamm dann wenig Priorität bekommt und Schritte nicht zählt.

    Ich habe etwas über die GPIO schaltfrequenz gefunden http://codeandlife.com/2012/07/03/ben…-pi-gpio-speed/, weiss aber nicht, ob das auch umgekehrt für die Eingänge gilt.
    Kann auch sein, das ich bei der Frequenzberechnung etwas falsch gemacht habe.

    Auf jedenfall, kann mir jemand sagen, ob ich hier Probleme bekomme, das Signal vom Encoder auszulesen?
    Ich habe schon noch weitere sachen gelesen, wo andere Kernel etc. verwendet werden, würde aber gerne beim originalen Raspian bleiben (Wheezy). Ohne noch am Kernel zu schrauben.

    Oder muss ich das ganze mit weiteren Elektronik Chips etc. angehen, welche ich zwischen Encoder und RPI setzen muss?

  • Du hast das zwar kompliziertest moeglich gerechnet - ich haette jetzt ja einfach 6533*100 / 60 genommen - aber die Groessenordnung von 11kHz bleibt bestehen. Und ja, da wird es mit Python knapp, aber selbst mit pigpio und C wuerde ich das nicht machen. Denn auch da gibt es keine Garantie bezueglich des Schedulings etc. In meinen Augen muss ein dezidierter uC her. Ooooder:

    Lustigerweise kenne ich deine Motoren - die habe ich naemlich in einem Kit das ich vermacht bekommen habe & mit dem ich einen Roboter bauen will. Dort ist es die 1:30 Getriebevariante, aber viel wichtiger: dabei ist ein MD23 genanntes Controlboard dabei, welches mittels I2C angesteuert wird, und dank dessen ich mich nicht mehr um das auslesen der Encoder kuemmern muss - sondern sogar schon Geschwindigkeitsregelung vorfinde.

    http://letsmakerobots.com/content/md23-d…dge-motor-drive

    Vielleicht hilft dir das, mindestens als Inspiration (den ganzen Rest deines Threads hab' ich jetzt nicht gelesen, ob du da noch spezielle andere Dinge brauchst).


  • Du hast das zwar kompliziertest moeglich gerechnet - ich haette jetzt ja einfach 6533*100 / 60 genommen - aber die Groessenordnung von 11kHz bleibt bestehen. Und ja, da wird es mit Python knapp, aber selbst mit pigpio und C wuerde ich das nicht machen. Denn auch da gibt es keine Garantie bezueglich des Schedulings etc. In meinen Augen muss ein dezidierter uC her. Ooooder:

    Lustigerweise kenne ich deine Motoren - die habe ich naemlich in einem Kit das ich vermacht bekommen habe & mit dem ich einen Roboter bauen will. Dort ist es die 1:30 Getriebevariante, aber viel wichtiger: dabei ist ein MD23 genanntes Controlboard dabei, welches mittels I2C angesteuert wird, und dank dessen ich mich nicht mehr um das auslesen der Encoder kuemmern muss - sondern sogar schon Geschwindigkeitsregelung vorfinde.

    http://letsmakerobots.com/content/md23-d…dge-motor-drive

    Vielleicht hilft dir das, mindestens als Inspiration (den ganzen Rest deines Threads hab' ich jetzt nicht gelesen, ob du da noch spezielle andere Dinge brauchst).

    Damit habe ich gerechnet.
    Hmm so wie ich jetzt lese, haben auch mC's Probleme damit (Also ich bin mir noch die Arduinos am anschauen). Weiss nicht, ob die als reine mC's gelten. Aber die haben so wie ich das sehe auch etwas Probleme beim so einer hohen Frequenz. Ob mir der md23 wirklich hilft, weiss ich noch nicht genau, da muss ich noch mehr darüber lesen; so beim Überfliegen sehe ich, das er mehr die Geschwindigkeit etc. regulieren kann). Eigentlich muss ich nur anhand der Impulse nur berechnen können, wie weit der Motor noch drehen muss, für eine bestimmte position. Also ich könnte dann evtl. auf einen Arduino umsteigen, müsste dabei aber noch C## lernen. Jetzt habe ich aber etwas von "Timer" gelesen. Ich muss so wie ich das mitbekommen habe, keine Flanken auswerten (Drehrichtung ist mir bekannt). Sondern brauche nur einen Impuls, den ich auswerten kann, um die Position bzw. den zurückgelegten Weg zu berechnen. Ich denke mit dem Timer bin ich der Lösung auf der Spur. Ansonsten wie du geschrieben hast, schaue ich mir auch den md23 an. Auf jedenfall gibt das ganze ein paar gute Anregungen um das Problem zu lösen. Danke.

  • Den md23 scheint's nicht mehr zu geben, ist jetzt md25 - Prinzip ist aber gleich. Und so weit ich weiss, kann der durchaus auch einen Stellbetrieb, sprich eine Position anfahren. Ob der Arduino schnell genug ist weiss ich nicht - der Propeller ist es definitiv, und den benutze ich mit dem Propeller HAT von Pimoroni. Tolles Teil.

  • Danke ja auf den "md25" bin ich auch gekommen, da der Link nicht mehr gültig war von deinem zum Datasheet.
    Der Pimoroni sieht ja toll aus. Nur ist der bei uns nicht direkt verfügbar und wäre froh wenn ich einfach zum nächstgelegenen Shop laufen kann und mir einen neuen kaufen, wenn ich den warum auch immer geschmort habe ohne auf Lieferzeiten warten zu müssen etc. Daher also wenn es geht nur per uC das ganze zu lösen.

    Also ich könnte daher alternativ auch auf einen Arduino umsteigen.
    z.B. Arduino mega 2560 habe ich mir angeschaut.

    Was ich nicht kapiere. Jetzt bin ich seit 3 Tagen am forschen, ob das ganze wirklich funktionieren wird, mit nur einem Arduino ohne vorgeschaltete IC's wie Counter etc.
    Kann mir jemand daher sagen, ob ich da Probleme bekomme?

    Ausgangslage:
    DC Motor welcher mit 11k RPM dreht mit einer Untersetzung von 100:1.
    Bei 12V werde ich Signale von dessen Encoder der Kanäle A & B bekommen von ca. 11kHz. Diese muss ich dann korrekt auswerten, damit ich den zurückgelegten Weg richtig berechnen kann. Mit welchen library's/Routinen etc. ich das ganze machen muss, bin ich auch noch am eruieren, bezüglich Fehlern wie Prellen usw.
    Weiterhin kommt dann auch noch ein LCD zum Einsatz, mit 4 buttons welcher über I2C läuft. Dies um (bevor der Motor Läuft) zu ändern.
    Während der Motor läuft soll das LCD dann jeweils Statusinfos anzeigen können. Hier gibt es keine sich schnell ändernde Aktualisierungen.

    Anhand von Beispielcodes / Libraries etc. werde ich das ganze dann schon zusammengebacken bekommen hoffe ich. Mir macht einfach die hohe Frequenzzahl der Pulse Sorgen.
    Daher kann mir da jemand sagen, ob ich das mit einem Arduino hinbekomme, oder ob ich doch noch vorgeschaltete Logik brauche?
    Weil ich muss ehrlich sagen, das ich dem ganzen dann evtl. nicht mehr gewachsen sein werde.

    p.s. zum md25 bin ich noch unschlüssig.
    Ich so wie ich das sehe wandelt dieser die Flankenimpulse von Kanal A&B in einen einfachen Puls um. Dieser wird dann an den uC zurückgeliefert. Wahrscheinlich in der gleich schnellen Puls also auch 11kHz. Daher hätte ich wahrscheinlich noch die gleiche Problematik wie zuvor, einfach mit einem Kanal weniger.
    Der md25 habe ich gesehen, ist für Motoren designed, welche 360 counts pro Umdrehung liefern. Mein gewünschter Motor liefert aber 6533 counts pro Umdrehung. Da schaue ich noch, ob der das vertragen würde.

  • Der MD25 handelt die komplette Ansteuerung ab - du hast nichts mehr zu tun mit dem zaehlen von Pulsen. Du liest die gesammelten Pulse ueber die Register Enc1x aus, und hast einen 32-Bit-Wert mit der Motorposition. Du kannst dann, wenn du dich der Endposition naeherst, entscheiden die Geschwindigkeit runter zu regeln. Diese Kontrolle findet im ~10 Hertz Bereich statt, dafuer sind der PI und sein I2C lange gut genug.

    Was die ATMELs angeht: es gibt spezielle Varianten, welche diese QDECs in Hardware ansteuern koennen, wenn du also darauf bestehst das selbst zu machen, dann benutz einen, der das beherrscht: http://www.atmel.com/images/doc8109.pdf. Damit bekommst du - analog zu dem gerade gesagten - Counter-Register, die du nur noch auslesen musst, und selbst wenn's mal etwas laenger dauert, verlierst du keine Pulse.


  • Der MD25 handelt die komplette Ansteuerung ab - du hast nichts mehr zu tun mit dem zaehlen von Pulsen. Du liest die gesammelten Pulse ueber die Register Enc1x aus, und hast einen 32-Bit-Wert mit der Motorposition. Du kannst dann, wenn du dich der Endposition naeherst, entscheiden die Geschwindigkeit runter zu regeln. Diese Kontrolle findet im ~10 Hertz Bereich statt, dafuer sind der PI und sein I2C lange gut genug.

    Was die ATMELs angeht: es gibt spezielle Varianten, welche diese QDECs in Hardware ansteuern koennen, wenn du also darauf bestehst das selbst zu machen, dann benutz einen, der das beherrscht: http://www.atmel.com/images/doc8109.pdf. Damit bekommst du - analog zu dem gerade gesagten - Counter-Register, die du nur noch auslesen musst, und selbst wenn's mal etwas laenger dauert, verlierst du keine Pulse.

    Danke vielmals. Das bringt Licht ins Dunkel. Jetzt muss ich mich nur noch für einen der beiden Wege entscheiden :-).

    Noch eine Frage am Rande. Warum machen die Hersteller Encoder mit so einer hohen Pulszahl? Ich meine, mit 6533CPR ist das ja eine Auflösung von 0.0551 Grad.
    Ist das einfach weil da ein Standardencoder von 64CPR auf einer 100:1 Untersetzung ist, und man dafür auch einen Standardmotor nimmt, damit nicht zu viele Varianten entstehen und somit, jemand der eine z.B. 5:1 Untersetzung wählt trotzdem noch eine gute Auflösung erhält? Oder denke ich in die falsche Richtung.

  • Zu wenige Impulse zu haben ist ein echtes Problem, weil man dann keine gute Regelung bauen kann. Zu viele gibt's eigentlich nicht - zaehlen ist ja billig, und wenn es dich stoert, haeng einen Hardware-Counter dazwischen, welcher das Signal zB durch 4 oder 8 oder 16 dividiert. Oder mach das in Software. Und 64/Umdrehung am Motor ist auch nicht super viel.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!