Noch österlich melde ich mich aus dem dazugehörigen Kurzurlaub zurück!
Herzlich willkommen an die beiden neu Hinzugestoßenen Olli und Aiko!
Zitat von derOlli im Beitrag #49
Vielleicht kann ich mit Ideen aushelfen.
Da bin ich mir gewiss! Ein Zugkarussel/-revolver ist schon eine feinmechanische Herausforderung; ich glaube nicht, dass ich das zustande bringen würde. Meinen vollen Respekt vor dieser baulichen Leistung. Wenn auch die Wirkprinzipien unterschiedlich sind, so werde ich bestimmt noch die eine oder andere Anregung bekommen können.
Zitat von apras im Beitrag #50
Auch ich habe vor einige Zeit ein Loklift selber gebaut, der zwar Ähnlichkeiten aber in die Konzeption auch größere Unterschieden gibt. In einem Holländischen Forum habe ich schon darüber berichtet, aber hoffentlich werde ich bald Zeit finden auch im StummiForum etwas darüber zu erzählen.
Unbedingt! Ich glaube, dass viele Modellbahner - außer die Schloss- und Lagerhallenbesitzer unter uns - aufgrund des ewigen Platzproblems mit dem Gedanken nach Lösungen wie diesen suchen. Wenn du magst, poste gern den Link zum holländischen Forum, ich würde ihn in die Liste in #0 aufnehmen.
Zitat von apras im Beitrag #50
In deine Berichte lese ich das du am Liebsten mit eine ESP32 arbeitest, aber "trotzdem" im moment mit ein Arduino UNO experimentierst. Aber warum benutzt Du nicht beides? In meinem Project benütze ich mehrere Procesoren. Ein ATMega 328 (UNO) "versorgt" (über Treiber) die Schrittmotoren (ich habe 2 paralel), ein ATMega 2560 versorgt die Bedienungstasten (und LEDs), noch ein 2560 wird für die (12 stück) IR-Lichtschleusen gebracht und schließlich gibt es noch ein ATMega 2560 der den DCC und RS-Bus interfaces implementiert und alles zusammen bindet.
Den ATMega 328 (UNO) dreht Standard GRBL (V1.1), und wird über die Serielle Verbindung am zentralen 2560 angebunden. Der 2560 sendet (zur Beispiel) nur X250.0, und der 328 sorgt dafür das der Schrittmotor sich zur Position "25 cm vom Anfang" begibt. Mit (jede Sekunde) ein GRBL "?" Kommando weiss der 2560 wo im Moment der Schrittmotor sich befindet.
Standard GRBL zu benützen hat auch viele weitere Vorteile, wie zur Bespiel (einstellbare) Beschleunigung, Abbremsen, Homing, usw. In meinem project habe ich vieles selber programmiert, aber gerade die Ansteuerung von Schrittmotoren ist nicht trivial und kann besser von einem Separaten Prozessor (mit GRBL) versorgt werden.
Meine "Empfehlung" wäre also über den Einsatz von GRBL und die Verteilung der Aufgaben über mehrere Prozessoren nach zu denken.
Das wird jetzt eine längere Antwort, fürchte ich.
Zunächst habe ich erst nach GRBL gegoogelt, das kannte ich noch nicht. Das klingt tatsächlich interessant und ist bestimmt eine gute Lösung im Selbstbau von CNC-Maschinen oder Druckern. Dort gibt es ja bis zu drei Bewegungsachsen zu koordinieren. Du hast, wenn ich es richtig verstehe, zwei Schrittmotoren, die für den Verschub sorgen. Das bringt schon einmal die doppelte Kraft, aber auf der anderen Seite hätte ich Angst, dass die Synchronisation nicht stimmt und sich die Mechanik dadurch gegenseitig beeinflusst und im schlimmsten Fall zerstört. Ich tippe darauf, dass du dann closed-loop-Schrittmotoren verwendest, um auf jeden Fall Schrittverluste auszuschließen?
Weiter schreibst du, dass die Schrittmotoransteuerung einschließlich Beschleunigung nicht trivial ist. Ich habe bisher die AccelStepper-Library benutzt. Die regelt das Berechnen der Beschleunigung/des Abbremsens für mich, so dass ich mich darum nicht kümmern muss. Allerdings habe ich sie noch nicht ohne Abstürze auf einem ESP8266 oder ESP32 zum Laufen gebracht und versuche daher jetzt die FastAccelStepper-Libary, die hoffentlich auf diesen anderen Prozessorarchitekturen funktioniert.
Da sie innerhalb der loop()-Funktion regelt (feststellt, ob noch Schritte zum Zielschritt fehlen), wird der Code sehr einfach: Ich brauche nur über zyklisches Abfragen der IR-Fernbedienung feststellen, welche Eben ausgewählt wurde, dann die Zielschrittposition anwählen, und das war es dann - den Rest besorgt die loop(). Ebenso hat übrigens die AccelStepper- (und ich vermute ebenso die FastAccelSteller-)Library Methoden, um mehrere Stepper gleichzeitig zu betreiben, das würde deinen Anwendungsfall vermutlich mit abdecken können.
Da die ESP-Prozessoren etwa 10mal leistungsfähiger sind als die Arduino UNO/MEGA, sehe ich auch keine Probleme mit der zusätzlichen Last durch Eingabeabfrage (Infrarot) oder Webserverbedienung (für eine browserbasierte Bedienung). D.h. ich werde unbedingt nur mit einem Mikroprozessor auskommen können. Wie gesagt, das Levelshiftung 3.3V -> 5V muss ich ggf. noch hinzufügen. Wobei ich Beispiele gelesen habe, wo jemand die Steppertreiber auch mit 3.3V erfolgreich betrieben hat. Das gilt es auszuprobieren, hoffentlich ohne dadurch hervorgerufene Schrittverluste.
Du hast bei deiner Lösung noch etliche Inputs mehr (Lichtschranken) und benötigst daher auch mehr GPIOs, da sind MEGAs mit ihren vielen GPIOs natürlich sehr gut. Ich kann meinen Zuglift gut einsehen und sehe keine Lichtschranken vor. Auch benötige ich keine weiteren Prozessoren für Gateways wie du - alles in allem ist meine Lösung simpler in der Zielstellung als wohl deine, aber das ist je nach Anwendungsfall auch in Ordnung.
Wie hast du das Speichern der aktuellen Position gelöst? Am einfachsten wäre es, die Schrittposition in den EEPROM-emulierenden Flash zu schreiben und nach Neustart einfach auszulesen. Allerdings habe ich Angaben über nur 100.000 Schreibzyklen gefunden. Wenn ich nach jedem Verfahren des Liftes (Stillstand abwarten statt jeden einzelnen Schritt zu schreiben) einspeichern würde und jede Woche den Lift 100 mal verfahren würde, würde das 1000 Wochen = rund 20 Jahre bedeuten. Gar nicht mal so schlecht, aber ich bin vorsichtig. Übervorsichtig? Es gäbe ja noch die Lösung, den Lift immer in eine definierte Position, die Schrittposition 0 entsprechen würde, bei Betriebsschluss zu verfahren. WIe machst du das?
.
): Ich habe die Ebene T verkabelt, so dass IR-Sensor, Motor, Treiber, yC (Microcontroller) verbunden sind:
