Weder der Schrittmotor noch die Firmware wissen in welcher Position sich der Motor tatsächlich befindet. Da der Motor keine Rückmeldung betreffend der Position liefert (oder liefern kann) nimmt die Firmware einfach an, alles wäre in Ordnung. Das klappt ja beim 3D Druck eigentlich recht gut (meistens). Gelegentlich geht irgendeine Kleinigkeit daneben, ein Schrittmotor ‚verliert‘ einen oder mehrere Schritte, und -schwupps- hat man wieder was für die Recyclingtonne produziert .
Beim CNC Fräsen klappt es meistens auch, obwohl hier, meiner Meinung nach, die Ansprüche ungleich höher sind. Beispielsweise bewegt sich beim 3D Druck das Werkzeug (die Düse) normalerweise immer weiter vom Werkstück (vom Druckbett) weg, womit eigentlich nie ein direkter Kontakt besteht, beim Fräsen ist hingegen eine ‚Kollision‘ ja vorgesehen und erwünscht. Wo sollten sonst die Späne herkommen? Durch diese Konstellation ergeben sich deutlich öfters Situationen, wo ein ‚verlorener‘ Schritt eines Schrittmotors zu mehr als nur Ausschuss führen könnte: hier sind gebrochene Werkzeuge oder Werkstücke, sogar ernste Verletzungen möglich.
Industriemaschinen (und auch –roboter) verwenden daher meist Systeme, wo die Ist-Position jedes Motors bekannt ist, bzw. zurückgemeldet wird. Sollte es irgendwann eine Diskrepanz zwischen Soll- und Ist-Position geben, bleibt die Maschine stehen (quasi ein Not-Aus), oder ähnliches.
Eine häufig eingesetzte Methode zur Positionsermittlung ist ein sogenannter Drehgeber (Rotationskodierer oder Rotary Encoder). So ein Drehgeber erkennt, oft auf optischem Weg, die jeweilige Winkelposition. Besonders raffinierte Systeme behalten auch die Anzahl der Umdrehungen im Auge.
Ich stelle hier also einen (funktionierenden?) Drehgeber vor, dessen Hauptbestandteile am RF1000 gedruckt wurden (mit 0.35 und 0.2mm Düse):
Der Drehgeber hat eine Auflösung von 8 Bit, womit bei einer vollen Umdrehung 256 unterschiedliche Werte erkannt werden können (entspricht 1.40625°). In unseren Druckern sind Schrittmotoren mit 200 Schritten eingebaut (entspricht 1.8°). Damit ist der Drehgeber theoretisch genauer als ein ganzer Schritt eines der Schrittmotoren (und ‚verlieren‘ kann man immer nur einen oder mehrere ganze Schritte).
Die Abmaße des Drehgebers sind 44x44x16mm (ohne Kabel, usw.). Ein NEMA 17 Schrittmotor, wie in den meisten 3D Druckern verwendet, hat 43x43xLänge (unterschiedlich). Somit hat der Drehgeber ungefähr dieselben Maße wie die Motoren: Elektrisch steckt nichts Besonderes dahinter, bloß 8 IR-LEDs und ebenso viele Phototransistoren, beide in der 3mm Ausführung. Für die LEDs sind Vorschaltwiderstände nötig. Für die Phototransistoren werden Pull-Up Widerstände benötigt damit das erzeugte Signal erkannt werden kann. Details später…
Ich habe versucht ein Video zu machen, was nicht sonderlich gut gelang. Daher hier ein Bild des funktionierenden Versuchsaufbaus: [list
- Bei ‚A‘ sieht man den eigentlichen Drehgeber. Hier sind noch alle Beinchen der LEDs und Phototransistoren in voller Länge vorhanden - daher sieht es ein wenig unförmig aus.
- ‚B‘ ist bloß ein Schraubendreher als Input-Medium, um die Unterbrecherscheibe drehen zu können
- ‚C‘ ist die Steuereinheit zur Signalauswertung – hier ein Arduino AT Mega 2560 – es besitzt einen Prozessor, der sehr ähnlich ist wie jener, auf dem die RFx000 Drucker basieren. Das Board ist hier ‚Overkill‘, also für die Aufgabe weit überdimensioniert (siehe dazu ‚G‘)
- ‚D‘ ist eine optionale Anzeige damit man sieht ‚was läuft‘ – tut eigentlich nichts zu Sache. Im Bild ist es kaum als Anzeige erkennbar da die Kamera ‚zu schnell‘ fotografiert und das Display Zeilenweise aufgebaut wird. Die Anzeige zeigt in der ersten Zeile den Winkel, in der zweiten den Status der 8 Sensoren als binäre Zahl, z.B. 10110111.
- Bei ‚E‘ und ‚F‘ sieht man die LED Vorwiderstände, bzw. die Pull-Up Widerstände für die Phototransistoren. Ich hatte die benötigten Werte nicht bei der Hand und musste jeweils 2 in Serie schalten um den geforderten Wert ungefähr hin zu bekommen. Streng genommen könnte man zumindest bei den IR-LEDs alle 8 in Serie schalten und mit nur einem einzigen Widerstand auskommen. Jemand, der in der Elektronik mehr bewandert ist als ich es bin, hat mir davon abgeraten. Bei den Phototransistoren kommt man um die 8 Widerstände nicht herum. Es kann sogar sein, dass diese nicht alle denselben Wert benötigen (bei mir zumindest).
- ‚G‘ zeigt ein Wemos D1 Mini, eine kleine Platine die imstande wäre, die gestellte Aufgabe zu lösen – man benötigt einfach 8 digitale Eingänge. So wie ich das erkennen kann, hat der D1 Mini mindestens 9 digitale IO pins. (Der Wemos D1 Mini ist sogar WiFi fähig, könnte somit die Werte drahtlos ins Netz speisen.) Der Wemos D1 Mini ist hier nicht nötig, könnte aber anstatt dem AT Mega 2560 eingesetzt werden.
- ‚H‘ zeigt als Größenvergleich einfach einen üblichen NEMA 17 Schrittmotor. Der Motor ist hier natürlich nicht nötig.
Ich kann hier aus mehreren Gründen keine eindeutige Aussage treffen:
- Einmal sind insgesamt an die 100 ‚wackelige‘ Steckverbindungen mittels Steckbrücken oder gesteckte Bauteile auf dem Breadboard im System. Die einzigen Lötstellen sind, dass jeweils ein Bein aller IR-LEDs und jeweils ein Bein aller Phototransistoren miteinander verbunden wurden da diese alle an Plus oder Minus gelegt wurden (damit wurden 14 Kabel eingespart). Durch die Steckverbindungen, zusammen mit den scheinbar steifen Kabeln, reicht manches Mal nur eine kleine Bewegung des Drehgebers und ein falsches ‚Signal‘ wird gesendet. Diese Probleme sollten mit einer fixen Montage (= alle Teile & Kabel gelötet) nicht mehr vorhanden sein.
- Andererseits sind die Löcher in den jeweiligen Masken sowie in der Unterbrecherscheibe schon sehr an der Grenze des Druckbaren und weichen eventuell ein wenig zuviel ab (mehr dazu später). Dadurch kommen vielleicht grenzwertige Signale zustande, welche zu den gelegentlichen Schwankungen führen? Eigentlich sollte der hier eingesetzte Gray Code solche Fehler vermeiden (oder gar ganz ausschließen?), ich weiß es nicht.
- Die gelegentlichen Schwankungen, die beobachtet wurden, sind vielleicht eine Folge der Programmierung. Nachdem das Programmieren in Arduino überhaupt nicht meine Stärke ist, könnte der Hund da begraben liegen. Nibbels könnte vermutlich mehr dazu sagen.
Ich kann bei Interesse die Stückliste, die CAD Modelle und das Arduino Skript ins Forum stellen.
Mehr im nächsten Beitrag.
Allseits Gesundheit!
mjh11