ich bin auf der Suche nach Informationen für ein Projekt, in dem ich bis zu 600+ Schrittmotoren einzeln ansteuern kann.
Meine Fragen dazu:
Die Ansteuerung kann ich mir über ein Raspberry Pi 5 vorstellen, welche Software (Programmieren kann ich) benötige ich dazu?
Welche Bauteile gibt es, an den ich alle Schrittmotoren anschliessen und Adressieren kann?
Welche Schrittmotoren kann ich am besten einsetzten, Preis/Leistung sollte stimmen, max. 10 - 20 mm breit, 360 Grad, <= 1 Grad ansteuerbar, Vorwärts- und Rückwärtslauf.
Welche Schrittmotoren-Steuerung wird für die Motoren benötigt?
Über den ein oder anderen Tipp oder ausführlichere Informationen würde ich mich sehr freuen.
DANKE!
Viele Grüß Frank
600 Motoren, Tausend Fragen, kein eigenes Konzept, keine konkreten
Angaben, geheimes Projekt, frisch angemeldet..ich hol mal Popcorn und
Cola.
Wenn’s keiner der üblichen Trollbeiträge ist, ist es bestimmt wieder ein Kunstprojekt. Technische Details sind da eher Nebensache. Hauptsache, es dreht sich, und kostet nix.
NEMA17 hört sich nicht direkt nach max. 10 - 20 mm Breite an, wobei nicht wirklich klar ist, was der TO mit "max. 10 mm ... breit" meint, wenn dann 20 mm wohl passen würde.
Wenn die Motoren nicht zur gewünschten Größe passen kann er sie hinten in einer großen Kiste verstecken? Mehr Fragen hätte ich zum plötzlichen Stromverbrauch von 600 angesteuerten Schrittmotoren ... Mit dem Wissen wächst der Zweifel.
Bei 600 Motoren wird die Kommunikation eine Herausforderung, denn die sollen sich ja vermutlich synchron zueinander bewegen. Ggf. Bewegungsabläufe vorher laden und dann über eine gemeinsame Taktleitung synchronisieren. Kostentechnisch würde der Bus ja auf RS485 oder CAN hinauslaufen, da können aber nicht alle 600 Teilnehmer an einen gemeinsamen Bus, jeweils nur so ca. 30..60 pro Strang.
Die Motoren sollen über Zahnräder Kunststoffzeiger
Wozu die Zahnräder?
Es sollen 2 Kunststoffzeiger auf einer Achse sein, wobei jeder Zeiger einzeln sich Vorwärts oder Rückwärts drehen soll (Uhren ähnlich), über zwei Schrittmotore. Jedes einzelne Segment soll nachher quadratisch ca. 8x8cm sein.
Nema17 klingt schon mal gut, ist aber mit 42,3mmm mir zu breit.
@ Harald A: Ja, über die Programmierung möchte ich verschiedene Einstellung ansteuern, das kann sein, dass sich alle Zeiger gleichzeitig oder aber auch nacheinander oder mehrere gleichzeitig bewegen sollen.
Welche Bauteile gibt es, an den ich alle Schrittmotoren anschliessen und
Adressieren kann?
Welche Schrittmotoren kann ich am besten einsetzten, Preis/Leistung
sollte stimmen, max. 10 - 20 mm breit, 360 Grad, <= 1 Grad ansteuerbar,
Vorwärts- und Rückwärtslauf.
Welche Schrittmotoren-Steuerung wird für die Motoren benötigt?
All das entscheidet über die sinnvolle und preiswerte Umsetzung. Um so klüger DU bist, um so eher wird es was.
Dumme Leute verwenden 600 Schrittmotortreiber, immerhin step und dir alle parallel und 600 enable decodiert.
Klügere versuchen sich in Matrixansteuerung, aber da eine Schrittmotorspule die andere ansteuert, also mitdreht, muss eine Entkopplung her mit Dioden für nur eine Stromrichtung. Also nur unipolare Schrittmotore.
Es sollen 2 Kunststoffzeiger auf einer Achse sein, wobei jeder Zeiger
einzeln sich Vorwärts oder Rückwärts drehen soll (Uhren ähnlich), über
zwei Schrittmotore. Jedes einzelne Segment soll nachher quadratisch ca.
8x8cm sein.
Nema17 klingt schon mal gut, ist aber mit 42,3mmm mir zu breit.
Ist komplett überdimensioniert, die Schrittmotoren müssen ja praktisch nur das Eigengewicht der Zeiger und etwaige Reibungsverluste und Haftmomente überwinden. Wenn man das nicht zu massiv aufbaut, sollten auch sehr, sehr viel kleinere Schrittmotoren ausreichen.
Es sollen 2 Kunststoffzeiger auf einer Achse sein, wobei jeder Zeiger
einzeln sich Vorwärts oder Rückwärts drehen soll (Uhren ähnlich)
Merkwürdige Uhr - normalerweise bewegen sich die Zeiger einer Uhr immer nur vorwärts im Uhrzeigersinn ;-)
Bei einem der Zeiger kannst du dir dann die Zahnräder sparen.
Auch bei der bewegen sich die Zeiger nur in eine Richtung.
Und was die Drehrichtung betrifft: Die Verbreitung von Uhren mit CCW-Zeigerbewegung ist doch arg beschränkt, ändert aber nichts an der traditionell unidirektionalen Bewegung ;-)
ich möchte mein Projekt nochmal auf dem Punkt bringen:
Ich will KEINE Uhren nachbauen.
Ich will nicht „Die Uhr wie im Ham Yard Hotel in London“ nachbauen.
Mich Interessieren keine Diskussionen die vor 10-13 Jahren geführt wurden, denn die Technik/Elektronik entwickelt sich ja weiter.
Ich suche eine elektronische Möglichkeit 600+ Schrittmotore über ein Raspberry PI einzeln anzusteuern, einen einzeln Motor über einen RB anzusteuern ist ja kein Problem aber 600+.
Danke an alle, die mir die Info zu den Schrittmotoren gesendet haben, das hat mir weitergeholfen, ich weiss nun in welcher Richtung ich suchen muss!
Fakt ist: Mit einem Raspberry only wird es definitiv nicht funktionieren. Das hat viele Gründe: Timing, I/O (selsbtverständlich) und nicht zu vergessen die Größe: Wenn von dem RP ein 3V3 Signal über drei Meter Leitung ausgegeben wird - da kommt hinten nicht mehr viel von an.
Schonmal Gedanken über Positionsbestimmung gemacht?! Also ist es wichtig in welcher Position die einzelnen Schrittmotoren stehen oder ist das egal? Weil du müsstest ja von 600 Schrittmotoren auch die Positionen abfragen wenn sie eine bestimmte Stelle anfahren sollen.
(Deswegen sind im übrigen in deinen Beispielen keine Schrittmotoren sondern Servos zum Einsatz gekommen)
Wenn von dem RP ein 3V3 Signal über drei Meter Leitung ausgegeben wird
da kommt hinten nicht mehr viel von an.
Eine Kupferleitung von drei Metern Länge hat bei einem Querschnitt von 0.25mm² einen Widerstand von 0,2Ω. Die Leitungskapazität sollte deutlich unter 1nF liegen. Warum soll dann von einem 3.3V Signal hinten kaum noch etwas ankommen?
Bisher hat der TO sich noch nicht zur Schrittfrequenz/Drehgeschwindigkeit geäußert.
Weil du müsstest ja von 600 Schrittmotoren auch die Positionen
abfragen wenn sie eine bestimmte Stelle anfahren sollen.
Das kommt darauf an, welcher Drehwinkel überstrichen werden soll. Wenn es einen Anschlag gibt, gegen den der Motor fahren kann, braucht man keinen Sensor.
Es macht einen riesigen Unterschied, ob man 600 Schrittmotoren nacheinander bewegen will, oder ob sich mehrere davon, schlimmstenfalls sogar alle, gleichzeitig, aufeinander abgestimmt, bewegen sollen.
Ersteres kann man relativ einfach hinbekommen, indem man je Motor einen Schrittmotortreiber nimmt. Deren digitale Eingangssignale kann man mit hintereinander geschalteten Schieberegistern erzeugen oder mit IO-Expandern.
Je nach dem, was für Schrittmotoren du aussuchst, kannst du die sogar direkt von Schieberegistern (mit Leistungsausgängen) ansteuern.
Die angesprochene Matrixschaltung kann den Schaltungsaufwand zu verringern.
Gehst du in die Autowerkstatt und sagst: An meinem Auto ist nicht der Blinker kaputt, es ist auch nicht der Scheibenwischer kaputt und auch nicht die Handbremse, genausowenig blablabla..
Statt zigmal zu schreiben, was du nicht willst, wäre es zielführend, wenn du stattdessen einfach schreibst, was du willst.
Also ganz einfach: was sollen die Motoren hier wie schnell bewegen?
einen einzeln Motor über einen RB anzusteuern ist ja kein Problem
Ingenieure würden sagen: wenn ich einen Motor ansteuern kann, dann muss ich lediglich das Datenprotokoll so anpassen, dass der eine Motor eine Adresse bekommt. Und dann reichen 600+ RPi aus, um 600+ Motoren anzusteuern. Ziel erreicht.
Was, zu teuer? Dann mache es so, dass je 1 billiger uC für 1€ je 1 Motor ansteuert. Auch das ist eine einfache Teilaufgabe des Projekts.
2,49€ pro Stück, also 1,5k€ nur für Motoren und Treiber. Dann würde ich Cluster bilden. Vielleicht so 5 Motoren pro uC. Billiges uC Board (z.B RP2040) für um die 2€. Nochmal 240€. Zusätzlich 120 CAN Tranceiver für um die 2€ das Stück. Nochmal 240€. Dann würde ich das alles auf eine Platine pro Cluster packen. Machen wir nochmal 200€.
Sind um die 2,2k€.
Da kommt dann noch Verbrauchsmaterialien , mehrere CAN Dongle für den Raspberry, Netzteile usw dazu.
Ich würde in diesem Beispiel Mal mindestens 2,5k€+ rechnen.
Dann hat man aber immernoch das Problem keine absolut Position der einzelnen Motoren zu haben. Wenn man die synchron haben möchte (Schrittverlust, Referenzierung nach Wakeup,...) wäre das aber evtl notwendig. Kann man aber nicht beurteilen mit den wenigen Infos.
2,2k€ bedeutet also grob 4€ pro Motor.
Mein erster Vorschlag von oben, der bis auf die Dimensionen passt ist nochmal ein Faktor 5 mehr.
Man sieht also, günstig ist ein weiter Begriff bei dem Projekt. Von dem Mörder Aufwand das alles ans laufen zu bekommen (Stichworte Verdrahtungsfehler, EMV,...) Mal ganz abgesehen.
Du möchtest dir das Leben extra schwer machen mit einem uC der keine
Echtzeit beherrscht.
Warum sollte der keine Echtzeit können?
Kennst Du die Anforderungen die gewünscht sind?
Es gibt ein RTOS dafür.
Deine Aussage ist so pauschal einfach nur falsch.
Mit FPGAs kann man da sicher was zusammenbauen um soviele gleichzeitig anzusteuern.
Nur wird das können fehlen.
Theoretisch könnte man für 16 Motoren einen µC verwenden, der die 64 Endstufen jeweis einzeln per Pin Toggeln im Timer macht.
Diese viele µC sind mit FD-CAN miteinander verbunden.
Damit wären 38 Stück davon nötig.
Wenn man jedem Motor 256 Teilungen geben würde, so könnte man mit einem FD-CAN Telegramm 64 Motoren ansteuern und für 600 Motoren wären dann nur 10 CAN Nachrichten nörig. Von der Geschwindigkeit her wäre das quasi zeitgleich.
Jedes Board bekommt 2 von diesen Radschaltern mit Teilung 0..9, damit kann man jedes Board adressieren und alle bekommen die gleiche Software. Ein Microcontroller mit 100 Pins sollte dafür ausreichend sein - sofern er FD-CAN kann. Ca. 90 IO Pins wären dazu nötig.
Der Raspi wird es ja wohl noch schaffen 10 CAN Nachrichten innerhalb weniger ms raus zu schicken.
Bitteschön, nur noch umsetzen.
PS: geht natürlich auch mit CAN, dann braucht es jedoch deutlich mehr CAN Botschaften und das Zeitgleiche verstellen wäre damit nicht mehr so gut gewährleistet.
Mich Interessieren keine Diskussionen die vor 10-13 Jahren geführt
wurden, denn die Technik/Elektronik entwickelt sich ja weiter.
Nein, für klasische Fragestellungen wie "Mach Licht mit Strom" oder "Beweg was mit Strom" werden die Lösungen der Vergangenheit immer noch angewandt.
Und 10-13 Jahre sind keine Zeit, auch der Raspi hat schon 13 Jahre auf dem Buckel. Und der Vorschlag mit dem CAN-Protokoll und Netzwerk aus Steuergeräten verwendet Technik aus dem Letzten Jahrtausend, CAN wurde u.a. von Bosch 1983 entwickelt.
Ich glaub hier fehlt jegliches Abstraktionsvermögen zur Konstruktion einer Anlage und gewünscht ist eher eine Kaufberatung. Dann schreib mal eine diesbezügliche Email an einen passenden shop wie reichelt, watterot, adafruit, ...
Für Informationen gibt es auch Fachbuchläden, gerade zum Raspberry gibt es einiges in dem auch das Thema Steppermotor als Crash-Kurs abgehandelt wird. (anbei Auszug aus ISBN: 978-3-8362-2933-3
DANKE für diesen vernünftigen sachlichen Beitrag.
Der Vorschlag setzt aber µC mit 64+ GPIO-Pins u.ä. voraus, die in Bastelkreisen und sonst ziemliche Exoten sind... da sind die anderen beiträge IMHO "vernünftiger" und dem TO scheint die Fähigkeit zwischen Vernunft und Unvernunft zu unterscheiden zu fehlen.
Also müßte man erst mal "Grundlagen" zu embedded elektronik klären.
Ich benötige keine weitere Post, da ich auf einen anderem Weg vernünftige Post mit sachlichen informativen Infos bekommen kann, was ich eigentlich hier erwartet habe.
Das es auch anders geht, sieht man an diesen Post‘s:
Um 600 Schrittmotoren mit einem Raspberry Pi zu steuern, ist ein direktes Ansteuern über die GPIO-Pins des Raspberry Pi nicht möglich, da ein einzelner Motor typischerweise mindestens zwei bis vier GPIOs benötigt und der Pi nur eine begrenzte Anzahl an Pins hat. Hier ist ein Überblick über praktikable Ansätze und die technischen Herausforderungen:
Herausforderungen
GPIO-Anzahl: Selbst mit GPIO-Expandern ist die Anzahl der direkt steuerbaren Motoren pro Pi stark begrenzt, da jeder Schrittmotor mehrere Steuerleitungen benötigt.
Stromversorgung: Die Motoren dürfen nicht direkt vom Pi versorgt werden – jeder Motor braucht einen eigenen Treiber und eine separate Stromquelle.
Synchronisation und Timing: Die gleichzeitige, präzise Steuerung vieler Motoren ist mit einem einzelnen Pi schwierig, da das Betriebssystem nicht für Echtzeitaufgaben ausgelegt ist.
Lösungsansätze
I2C GPIO-Port-Expander
Mit I2C-Port-Expandern wie dem MCP23017 lassen sich pro Expander 16 zusätzliche GPIOs gewinnen. Bis zu 8 dieser Expander können an einen I2C-Bus gehängt werden, was 128 zusätzliche GPIOs ergibt.
Für 600 Motoren (bei 4 GPIOs pro Motor) wären 2.400 GPIOs nötig, was die Kapazität eines einzelnen Pi deutlich übersteigt.
Lösung: Mehrere Raspberry Pis einsetzen, die jeweils einen Teil der Motoren steuern, und diese per Netzwerk oder seriell koppeln.
Multiplexer
Multiplexer wie der CD74HC4067 können mehrere Signale auf wenige GPIOs legen, sind aber für schnelle, gleichzeitige Steuerung vieler Motoren nicht geeignet, da immer nur ein Kanal aktiv geschaltet werden kann.
Für 600 Motoren ist das Konzept zu langsam und zu komplex.
Separate Microcontroller oder Motorsteuer-Boards
Eine bewährte Methode ist, jedem Motor (oder einer Motorgruppe) einen eigenen Mikrocontroller (wie Arduino oder ESP32) oder ein dediziertes Motorsteuer-Board zuzuweisen, das vom Raspberry Pi über ein Bussystem (z. B. I2C, SPI, UART, CAN) gesteuert wird.
So übernimmt jeder Mikrocontroller die exakte Ansteuerung „seiner“ Motoren, während der Pi nur noch Steuerbefehle verteilt.
Professionelle Steuerungssysteme
Für industrielle Anwendungen gibt es spezialisierte Steuerungs-Hardware, die viele Motoren über Feldbusse (z. B. Modbus, CANopen) ansteuern kann. Der Pi kann dann als zentrale Steuereinheit dienen.
Beispielaufbau für viele Motoren
Pro Motor ein Treiber (z. B. ULN2003A, TB6600).
Pro Pi maximal etwa 25 Motoren mit Port-Expandern (theoretisch, praktisch weniger wegen Timing und Bus-Limitierungen).
Für 600 Motoren: 24 Raspberry Pis mit je 25 Motoren, untereinander vernetzt.
-Alternativ: Jeweils ein Arduino pro 10–20 Motoren, alle Arduinos per serieller Schnittstelle oder I2C/SPI mit dem Pi verbunden. Der Pi sendet nur Steuerbefehle, die Arduinos setzen diese um.
Fazit
Direkt ist es nicht möglich, 600 Schrittmotoren mit nur einem Raspberry Pi zu steuern. Die Lösung besteht in einer verteilten Architektur mit vielen Motorsteuer-ICs, Expandern, mehreren Pis oder zusätzlichen Mikrocontrollern, die über ein Bussystem miteinander kommunizieren. Die praktische Umsetzung hängt stark von den Anforderungen an Geschwindigkeit, Synchronität und Zuverlässigkeit ab.
Unterschied zwischen Schrittmotor und Servomotor
Funktionsweise
• Schrittmotor: Ein Schrittmotor bewegt sich in festen, diskreten Schritten. Jeder elektrische Impuls dreht den Rotor um einen bestimmten Winkel. Die Steuerung erfolgt meist im offenen Regelkreis, d.h. ohne Rückmeldung über die tatsächliche Position. Der Motor kann eine Position anfahren, anhalten und halten, ohne dass ein Positionsgeber (Encoder) notwendig ist.
• Servomotor: Ein Servomotor arbeitet im geschlossenen Regelkreis. Er besitzt einen Sensor (meist einen Encoder), der die aktuelle Position oder Geschwindigkeit misst. Der Servoregler vergleicht ständig Soll- und Ist-Werte und passt die Motoransteuerung entsprechend an. Dadurch kann der Servomotor präzise Positionen auch bei wechselnden Lasten anfahren und korrigieren.
Drehmoment und Drehzahl
• Schrittmotor: Liefert bei niedrigen Drehzahlen ein hohes Drehmoment, das jedoch mit steigender Drehzahl stark abnimmt. Schrittmotoren eignen sich daher besonders für Anwendungen mit niedrigen Geschwindigkeiten und hoher Präzision.
• Servomotor: Bietet über einen großen Drehzahlbereich ein nahezu konstantes Drehmoment und kann kurzfristig sogar ein Spitzendrehmoment bereitstellen. Damit sind Servomotoren für dynamische Anwendungen mit hohen Geschwindigkeiten und wechselnden Lasten besser geeignet.
Positionierung und Genauigkeit
• Schrittmotor: Die Position ergibt sich aus der Anzahl der angesteuerten Schritte. Bei Überlastung kann es zu Schrittverlusten kommen, was die Positionierung verfälscht, da keine Rückmeldung erfolgt. Für absolute Stillstandsstabilität ist der Schrittmotor jedoch ideal, da er ein hohes Haltemoment besitzt.
• Servomotor: Dank Encoder-Feedback kann der Servomotor seine Position auch unter Last exakt einhalten und Korrekturen vornehmen. Das macht ihn besonders für präzise und dynamische Bewegungen geeignet, auch bei hohen Geschwindigkeiten.
Energieverbrauch
• Schrittmotor: Muss auch im Stillstand ständig mit Strom versorgt werden, um das Haltemoment aufrechtzuerhalten, was zu einem höheren Energieverbrauch führen kann.
• Servomotor: Nimmt nur so viel Strom auf, wie tatsächlich für die aktuelle Bewegung oder das Halten der Position nötig ist. Das spart Energie und reduziert die Wärmeentwicklung.
Kosten und Komplexität
• Schrittmotor: Einfacher Aufbau, günstigere Anschaffung und leichtere Ansteuerung. Ideal für Anwendungen mit geringem Budget und moderaten Anforderungen an Dynamik und Präzision.
• Servomotor: Höherer Preis und komplexere Steuerung durch den geschlossenen Regelkreis und zusätzliche Sensorik. Dafür aber deutlich leistungsfähiger und flexibler einsetzbar.
Unterschied zwischen Arduino und ESP32
Wesentliche Unterschiede
• Rechenleistung & Speicher:
Der ESP32 ist dem Arduino Uno in Sachen Prozessorleistung und Speicher deutlich überlegen. Während der Arduino Uno mit einem 8-Bit-Prozessor und 16 MHz arbeitet, bietet der ESP32 einen Dual-Core-Prozessor mit bis zu 240 MHz und ein Vielfaches an RAM und Flash-Speicher.
• Konnektivität:
Der ESP32 hat Wi-Fi und Bluetooth (Classic & BLE) bereits integriert, was ihn ideal für IoT- und Smart-Home-Anwendungen macht. Arduino-Boards wie der Uno verfügen über keine integrierte Funktechnik und benötigen dafür externe Module.
• Spannungsniveau:
Arduino Uno arbeitet mit 5 V Logikpegeln, der ESP32 hingegen mit 3,3 V. Das ist wichtig für die Kompatibilität mit Sensoren und Aktoren – 5 V an einem ESP32-Eingang kann diesen beschädigen.
• Programmierumgebung:
Beide Plattformen können mit der Arduino IDE programmiert werden. Der ESP32 unterstützt zusätzlich MicroPython und andere Entwicklungsumgebungen.
• Anwendungsgebiet:
Arduino eignet sich besonders für Einsteiger, Bildungsprojekte und einfache Steuerungsaufgaben. Der ESP32 ist prädestiniert für anspruchsvollere Projekte, die Netzwerkfähigkeit, höhere Geschwindigkeit oder mehr Speicher benötigen, etwa bei IoT-Geräten, Datenloggern oder komplexer Sensorik.
• Community & Support:
Beide Plattformen verfügen über eine große Community und viele Tutorials. Arduino ist besonders für Anfänger sehr gut dokumentiert, während ESP32 zunehmend an Popularität gewinnt und ebenfalls umfassend unterstützt wird.
Fazit
• Arduino ist optimal für Einsteiger, einfache Steuerungsaufgaben und schnelle Prototypen ohne Netzwerkbedarf.
• ESP32 ist die bessere Wahl für Projekte, die mehr Leistung, Speicher und vor allem integrierte Wi-Fi/Bluetooth-Konnektivität benötigen – etwa im Bereich Smart Home, IoT oder komplexe Automatisierung.
Die Wahl hängt letztlich von den Anforderungen des jeweiligen Projekts ab. Wer drahtlose Kommunikation und mehr Rechenpower braucht, greift zum ESP32. Wer Einfachheit und maximale Kompatibilität mit 5V-Hardware sucht, ist mit Arduino gut bedient.
Ich benötige keine weitere Post, da ich auf einen anderem Weg
vernünftige Post mit sachlichen informativen Infos bekommen kann, was
ich eigentlich hier erwartet habe.
Na dann haste ja deine Erwartungshaltung an die Realität abgleichen können, genau das macht Lernen an der Praxis aus.
Wer Einfachheit und maximale Kompatibilität mit 5V-Hardware
sucht, ist mit Arduino gut bedient.
Problem wird weniger die Steuerung als der Strombedarf/Hitzeentwicklung sein, ebenso das zurechtflechten der Kabelbäume. Aber solche Informationen benötigt der TO ja nicht.
Ist es so schwierig, vorher zu gucken, was du hochlädst?
Es ist schlicht unmöglich "vorher zu gucken", in der Artikel-Vorschau hier wird die Ausrichtung der Bilder (und die Bilder selbst) nicht angezeigt.
Man sieht erst nach der "Veröffentlichung" wie die Forumssoftware die Bilder ausrichtet. Und da gibt es immer mal wieder Unterschiede in der Ausrichtung zwischen Bildverarbeitungsprogramm und Forums-Gedöhns/Browser.
Das Thema "verdrehte Bilder" ist hier schon mehrmals andiskutiert wurden, aber letzlich muss der Forist damit leben und sich die Bilder so drehen wie er es grad braucht - selbst Windowsnutzer schaffen das inzwischen mit Bordmitteln und bei einem Smartphone genügt 'ne simple Hand-/Kopf-bewegung...
Abgesehen davon, das ich den Beitrag schon einmal gelöscht und neugesendet habe damit es mit dem ersten Bild passt. Und beim zweiten Bild passte es dann wieder nicht ... siehe Anhang: in der Bildverarbeitung beide gleich ausgerichtet im Forum dann unterschiedlich
Echt, man hat Besseres im Leben zu tun, als Hinz und Kunz den unbezahlten Hauslehrer zu geben ...
Hier ist ein Überblick über praktikable Ansätze und die
technischen Herausforderungen
Da haben wir wieder jemanden, der sich lieber von einem Chatbot beraten lässt, als von fachkundigen Menschen. Und dann meckert er auch noch, weil deren Ratschläge scheinbar komplexer sind, als die scheinbar einfache Lösung des Chatbots.
Wahrlich, ich sage dir: Wie alle anderen wirst auch du noch auf den Boden der Realität zurück kommen.
Müssen die Motoren, um die leichten Zeiger zu halten.
dauernd unter Strom stehen?
Oder könnte man die, über einen Treiber und ein
Multiplexer kurz nacheinander ansteuern?
Ich will KEINE Uhren nachbauen.
Ich will nicht „Die Uhr wie im Ham Yard Hotel in London“ nachbauen.
da der TO das trotz mehrmaliger Rückfrage nach Kräften verschweigt. Daher kann es keine sinnvollen Antworten geben. An denen der TO offensichtlich auch gar nicht interessiert ist. Halt ein Troll.
Es sollen 2 Kunststoffzeiger auf einer Achse sein, wobei jeder Zeiger
einzeln sich Vorwärts oder Rückwärts drehen soll (Uhren ähnlich), über
zwei Schrittmotore. Jedes einzelne Segment soll nachher quadratisch ca.
8x8cm sein.
Wenn ich der TO wäre, würd ich jetzt aus 4 Motoren ne Matrix
auf nem Brett machen und die offenen Fragen klären.
Das würde dann mein Prototyp sein, der mich in die
Lage versetzt weitere Fragen zu klären.
Ich mein nicht die elektr. Ansteuerung.
Ich würd klären ob die Motoren die Zeiger
ohne Ansteuerung in jeder Stellung halten können.
Diese Versuche können ne Menge Geld sparen! :-P
Es sollen 2 Kunststoffzeiger auf einer Achse sein, wobei jeder Zeiger
einzeln sich Vorwärts oder Rückwärts drehen soll (Uhren ähnlich), über
zwei Schrittmotore.
Diese Idee hatte ich gestern ebenfalls (mit den gleichen Schrittmotoren
und Darlingtontreibern, hatte aber noch keine Zeit, den Vorschlag
genauer zu beschreiben. Auf jeden Fall dürfte dies die mit Abstand
kostengünstigste Lösung sein (wobei bei Kunstwerken die reinen
Materialkosten oft gar keine Rolle spielen, da sie in den Gesamtkosten,
die der Künstler in Rechnung stellt, völlig untergehen ;-)).
Ich hätte die 1N4248 und die ZD24 weggelassen und stattdessen die im
ULN2803 und UDN2981 inregrierten Freilaufdioden verwendet. Jeweils eine
Freilaufdiode pro Zeile und Spalte der Spulenmatrix ist ja völlig
ausreichend. Damit sind immerhin 4800 Dioden mitsamt Lötaufwand
eingespart. Die 1N4148 braucht man natürlich trotzdem, um unerwünschte
Stromflüsse durch nicht angesprochene Motorspulen zu unterbinden.
Die Motoren bekommt man bei AliExpress bei Abnahme von 600 Stück schon
für unter 1€/Stück. Dazu kommen noch 2400 1N4148, 7 ULN2803, 6 UDN2981,
13 74HC595 und irgendein simples Mikrocontrollermodul für die
Ansteuerung. In Summe sind das also etwa 600€.
Etwas ungeschickt ist die relativ hohe Getriebeübersetzung der Motoren
von 64:1, was sie im Multiplexbetrieb nur sehr langsam drehen lässt.
Damit lassen sich zumindest 12 Motoren gleichzeitig bewegen.
Um etwas schneller zu werden, könnte man auch eine Auswahl von Motoren
in einer Matrixzeile (also bis zu 50) gleichzeitig um 4 Schritte in eine
Richtung und danach eine andere Auswahl derselben Zeile in Gegenrichtung
drehen lassen. Das Ganze wird für die restlichen 11 Zeilen wiederholt.
Man hat dadurch statt der 4096 Schritte/360° nur noch 1024, was aber
immer noch mehr als ausreichend sein dürfte.
Wenn das immer noch zu lange dauert, kann man noch das Seitenverhältnis
der Matrix anpassen, als bspw. 6×100 statt 12×50 Motoren. Man braucht
dann halt ein paar Treiber und Schieberegister mehr, aber die kosten ja
fast nichts.
Zur Abschätzung der maximal realisierbaren Geschwindigkeit müsste man
experimentell ermitteln, ab welcher Impulsdauer auf einer der vier
Phasen sich der Motor zuverlässig um einen Schritt weiterdreht.
Wie Lotta schon schrieb, ist es generell ratsam, das Ganze erst einmal
mit nur vier Motoren in eine 2×2-Matrix auszuprobieren, bevor man sich
allzu sehr in Unkosten stürzt (es sei denn, ChatGPT sagt, dass das alles
funktionieren wird, dann kann man natürlich auch direkt loslegen ;-)).
Für die Referenzierung würde ich eine Kamera verwenden, die alle 600
Zeiger auf einmal erfasst. Mittels Bildverarbeitung wird dann deren
Winkelposition ermittelt. Dies kann auch im laufenden Betrieb jederzeit
wiederholt werden, so dass auch verschluckte Schritte der Motoren kein
Problem sind.
Es sollen 2 Kunststoffzeiger auf einer Achse sein, wobei jeder Zeiger
einzeln sich Vorwärts oder Rückwärts drehen soll (Uhren ähnlich), über
zwei Schrittmotore.
Genau so ist es.
Der TO braucht also bereits 4 fertige Module mit der Mechanik.
Die muß er bauen, denn er macht ja Grundlagenforschung,
sein Gerät gibts ja nicht noch einmal.
Vorher muß er klären, das der dann 600 gleiche Motoren bekommen kann,
sonst ist sein Projekt gleich am Anfang erledigt.
Wenn dann der Prototyp steht und er die Ersten Erfolge melden
kann, wird er hier Freaks finden, die ihm helfen.
Ich habs mit Ralph Berres persönlich erlebt.
Ob der Motor dauernd unter Strom stehen muss oder das Rastmoment reicht, hängt davon ab, wie gut die Zeiger ausbalanciert sind.
Bevor der TO sich mit Projekten dieser Größenordnung befasst, tut er gut daran, sich mit den Grundlagen von Schrittmotoren zu befassen und selber ein bisschen Erfahrungen zu sammeln.
Aber der Allesproblemlöser ChatGPT wird's schon richten ;-)
Ob der Motor dauernd unter Strom stehen muss oder das Rastmoment reicht,
hängt davon ab, wie gut die Zeiger ausbalanciert sind.
Bevor der TO sich mit Projekten dieser Größenordnung befasst, tut er gut
daran, sich mit den Grundlagen von Schrittmotoren zu befassen und selber
ein bisschen Erfahrungen zu sammeln.
Dazu braucht er ja nen Prototyp.
Erst wenn der steht, können die Parameter ermittelt werden.
Wenn die Parameter bekannt sind, kann der Treiber erstellt werden.
Wenn der Treiber läuft, kann ein Arrangement-Programm geproggt werden.
Kurz: Der TO Frank ist in einem frühen Forschungsstadium und glaubt noch, dass KI alles für ihn erledigt. Seine Hausaufgaben sollte er mal schön selber machen. Einige Anregungen hat er jetzt.
Das statische Drehmoment eines mechanischen Aufbaus abzuschätzen, geht nun wirklich auch ohne. Datenblätter zu Schrittmotoren gibt es auch.
Ohne vorher ein ganz klein wenig zu rechnen, die Engpässe zu lokalisieren und eventuell konstruktiv noch eine Entwicklungsschleife zu drehen, verzettelt man sich sonst mit Prototypen.
Das statische Drehmoment eines mechanischen Aufbaus abzuschätzen, geht
nun wirklich auch ohne. Datenblätter zu Schrittmotoren gibt es auch.
Ohne vorher ein ganz klein wenig zu rechnen, die Engpässe zu
lokalisieren und eventuell konstruktiv noch eine Entwicklungsschleife zu
drehen, verzettelt man sich sonst mit Prototypen.
Naja, wenns nur um das Drehmoment geht magst Du ja Recht haben.
Wenn man aber kein Uhrmacher ist, der das ja täglich macht,
hätte ich lieber was handgreifliches.
Immerhin muß das Getriebe mit Hohlachse ja konstruiert,
mit nem 3D Drucker gefertigt und in selbstgefertigtes Gehäuse integriert werden.
Und dann muß die Ansteuerung der Uhren erdacht werden, da
ich nicht glaub, das standartmäßige Verfahren funzen werden, da
auch die Zeiten berücksichtigt werden müssen, etwa durch Ansteuerung
mit Zufallsgenerator, um ne scheinbare Gleichzeitigkeit der
Uhrenansteuerung zu simulieren.
Immerhin müssen ja 600 Motoren angesteuert werden, und wenn das von
"Oben" nach "Unten" geschieht siehts nicht gut aus.
