Druckbare Version
Ich würde es mit zwei Schrittmotoren angehen, für jeden Wickel einen.
Bestromt wird immer nur der 'ziehende', der 'gezogene' wirkt durch sein Rastmoment als Bremse (diese Wirkung ließe sich durch 'leichtes Kurzschließen' noch verstärken) und kann auch gleich als Drehzahlsensor genutzt werden.
Schrittmotor deshalb, weil bei diesen das Moment besser durch den Strom limitiert wird und für die Aufgabe des Umspulens während der Filmentwicklung sicher keine hohen Drehzahlen erforderlich sind.
KK
Eine Bremse ist es auch nicht. Wenn beide Wickel über den Riemen verbunden sind, dann bremst die Bremse auch beide Wickel. Was es aber bringt wäre eine elektromagnetische Kupplung (beziehungsweise 2 davon) Man kuppelt eben die Spule mit dem Antrieb, die aufwickeln soll, die andere bleibt ausgekuppelt. Die Drehrichtung mit der Kupplung zu synchronisieren ist elektrisch einfach. Ich denke aber, dass 2 getrennte Motoren letztlich einfacher und billiger sind als ein Motor, Riemenantrieb und 2 Kupplungen.
Konzeptionell also nochmal zurück zum Anfang, jede der beiden Wickelachsen bekommt einen Motor:
1. Getriebemotor: Darf keine hohe Übersetzung haben, sonst bremst der geschleppte Motor zu stark (vielleicht maximal 10:1). Dann bekommt man aber wahrscheinlich zu hohe Drehzahlen. Wenn man mit der Spannung zu stark heruntergeht, riskiert man, dass er stehen bleibt wenn die Reibung mal etwas höher ist. Die Drehzahlkonstanz wird also schwierig sein, außer man regelt aktiv, was aber wieder zusätzlichen Aufwand macht.
2. Schrittmotor: könnte direkt ohne Getriebe angebaut werden. Bremswirkung des geschleppten Motors ist gering aber offenbar auch nicht notwendig. Drehzahl unempfindlich gegenüber Schwankungen in der Reibung. Ansteuerung ist generell aufwendiger als beim Getriebemotor. Ich glaube nicht, dass man beim Filmende auf Null abbremsen muß, wenn man beim händischen Kurbeln bis zum Anschlag dreht, wird es nichts schaden, wenn der Motor das auch tut (zumindest wenn man den Motor nicht übermäßig kräftig auslegt und bei moderaten Wickelgeschwindigkeiten bleibt). Es würde also genügen nach einer bestimmten Zeit zwischen den Motoren umzuschalten.
Ich sehe gerade den Beitrag von Kabelkaspar. Kommt meinen Gedanken momentan ziemlich nahe.
Ja, leuchtet ein. Zurück zur Ausgangssituation, mit Schrittmotor.
Darf ich nochmals nachhaken ...? Keil- oder Zahnriemen? - Ich würde den Zahnriemen nehmen.
Was haltet Ihr von dieser Einkaufsliste:
1 x http://www.shop.robotikhardware.de/s...roducts_id=173
2 x http://www.shop.robotikhardware.de/s...roducts_id=172
Könntet Ihr mir noch einen Tipp geben, wo ich Riemen und entspr. Scheiben herkriege?
Herzlichen Dank im Voraus!
Wenn es 2 Motoren werden (wie zuletzt vorgeschlagen) dann braucht man keinen Riemen. Wenn Du mit 1 Motor arbeiten willst: ich sehe in dieser Anwendung kein Argument das für oder gegen den einen oder anderen Riementyp sprechen würde (ganz im Gegenteil, ich könnte z.B. noch Rundriemen hinzufügen). Der Vorteil des Zahnriemens ist die Freiheit von Schlupf, in dieser Anwendung aber nicht relevant. Also würde ich eher nach Preis und Verfügbarkeit entscheiden.
Edit:
Bezugsquellen für Riemen:
conrad.de
maedler.de
Maedler kannt ich nicht ... Besten Dank für alles!
Am Freitag kamen die Schrittmotoren, der Motortreiber und das USB/I2C-Interface an. Der Schrittmotortreiber (iSMT von ELV) benützt einen TMC223. Ich habe mir das Datenblatt zu dem Chip besorgt und durchgelesen.
Leider gibt's ein paar Verständnisprobleme meinerseits damit. Um hier niemandem Löcher in den Bauch zu fragen ... kann mir jemand eine Quelle für das Ansprechen von Schrittmotoren über I2C angeben, für Anfänger? - Die hauptsächliche Schwierigkeit besteht darin, den Motor eine bestimmte Anzahl Umdrehungen lang laufen zu lassen, um ihn dann zu stoppen. Ich nehme an, dies sollte über den Parameter "Target Position" möglich sein. Der Motor verhält sich aber äusserst seltsam diesbezüglich ... Besten Dank im Voraus!
Hast du dir die Sequenzliste, die man Downloaden kann, angeschaut? Vielleicht kannst du da die Sequenzen herauslesen. Die Datei kannst du mit dem normalen Editor öffnen falls du HTerm nicht hast und nicht downloaden willst.
Bei diesem DB steht auf S37 wie man eine bestimmte Position anfährt. Ich bin mir aber nicht sicher ob man Byte 2 und 3 auch senden muss oder nicht. Das könntest du eventuell aus der Sequenzliste herauslesen.
Wie steuerst du den Treiber an? vom PC oder µC?
MfG Hannes
Hallo Hannes,
HTerm hab' ich bereits installiert, und alles läuft soweit. Ich verwende das iSMT und das USB/I2C von ELV via PC, zusammen mit einem kleinen Schrittmotor (bipolar, 0,8A). Gestern habe ich mir die Datenblätter vom TMC223 und dem Baugleichen AMIS30624 zu Gemüte geführt. Wenn ich mir viel Mühe gebe, verstehe ich genug davon, um damit zu arbeiten :-)
Im von Dir ebenfalls angegebenen DB steht zwar auf Seite 44, dass der TMC223 keinen velocity mode unterstütze, allerdings ist es möglich mit dem Befehl "97" (vollständige Sequenz: s [adresse] 97 p) den Motor kontinuierlich anzutreiben. Das Problem besteht darin, dass dabei der Befehl "GetFullStatus2" die aktuelle Position nicht ausgibt. Dies ist nur der Fall, wenn ich die target position auf's Maximum (32767) setze und den Motor antreibe.
Eigentlich benötigte ich ein Skript, welches kontinuierlich die aktuelle Position des Motors ausliest und diese zurücksetzt, bis die gewünschte Anzahl Umdrehungen erreicht ist.
Kannst Du mir sagen, ob dies mit HTerm möglich ist? Bisher habe ich es nur geschafft "starre" Befehlsequenzen abzuspeichern und aufzurufen, nicht aber Rückgabewerte des Chips auszulesen und zu verarbeiten ...
Besten Dank im Voraus!
Patrick
Ich kenne HTerm jetzt nicht aber du könntest z.B. mit Python oder Processing (eigentlich Java, aber programmiert sich wie C++) versuchen die Daten von über den seriellen Port zu schreiben/lesen. Das geht ganz gut, außerdem kannst du dir deine Anwendung zurechtschneidern wie du sie gerne hättest --> kannst also auch die Daten verarbeiten und nicht "nur auslesen"Zitat:
Kannst Du mir sagen, ob dies mit HTerm möglich ist? Bisher habe ich es nur geschafft "starre" Befehlsequenzen abzuspeichern und aufzurufen, nicht aber Rückgabewerte des Chips auszulesen und zu verarbeiten ...
Ist eben nur eine Lösung wenn du Lust hast dir ein eigenes Script / Programm zu schreiben.
Nach einer Info-Odysee bin ich gerade dabei, mir die Processing-IDE herunterzuladen. Ich werde später 'mal etwas damit 'rumspielen ... Danke für den Tipp!