Repetier Extra Motor Driver bremst ungewollt ab

Grüß euch,

der eine oder andre hasts vielleicht schon gesehen, Repetier unterstützt seit einiger Zeit extra Motoren. Diese sind zum Beispiel dafür gedacht ein Dualhotend ala Stratasys zu kippen oder vieles mehr.
Ich wollte das Ganze dafür verwenden einen Schlitten mittels Zahnstange + Nema17 300mm weit zu bewegen.
Das einrichten war so einfach erledigt das ich es selbst kaum glauben konnte, mithilfe des Repetier-Firmware configuration tool's dem motor die entsprechenden pins zugewiesen, aufgespielt, Host gestartet und schon funktioniert alles!

Gesteuert wird der kleine Stepper mit:
G201 P X - Go to position X with motor X
G202 P X - Mark current position as X
G203 P - Report current motor position
G204 P S<0/1> - Enable/disable motor

Wenn doch eh alles so einfach ist, was will der typ dann eigtl hier, wird sich der ein oder andere fragen.
Tja - leider hab ich bei genauerem hinschauen ein seltsames Verhalten festgestellt. Lasse ich den Motor von 0 auf 300mm fahren fährt er dorhin, bremst aber aber auf seinem weg 5 mal bis zum Stillstand ab und fährt dann weiter. Bei verkürzen des Verfahrweges bremst er seltener ab. Reduziert man den Weg auf 25mm fährt er auf einmal durch.

Ist das normal so und ich muss einfach damit leben, oder kann man da noch was ändern?

Zu den Einstellungen in der Firmware:

Steps/mm 800
mm/min 150

Treiber ist ein DRV8825 auf nem RUMBA board.

Ich könnte gerne ein Video dazu nachreichen, nur weiß ich leider nicht wie man das hier im Forum hochlädt.


Danke schonmal an alle helfenden, und schönen Sonntag noch!


Gruß
Tom

Das nennt sich überhitzen des Treibers
Dein Strom scheint zu hoch zu sein, runter drehen und nochmal probieren

---

Commercium ----> Ramps, RADDS, e3d-Hotends und Filament kauft man hier.. und neu auch Schrauben,Muttern und Unterlegscheiben
Probleme mit dem e3d und bei mir gekauft? Schickt es ein, ich teste es für euch ob es wirklich defekt ist
Print Quality Troubleshooting Guide hier lang..

Hi Le-Seaw,

danke für die Anregung. Ich hab die den Motorstrom gemessen er war auf 1A eingestellt. Auch weiters reduzieren hat nicht den gewünschten Effekt erzielt (erhöhen aber auch nicht).
Zu guter letzt habe ich die Treiber von X Y und Hilfsmotor 1 untereinander mehrmals getauscht, das problem besteht weithin, allerdings nur beim "extra motor". ich habe auch die Motoren untereinander getauscht, da sich mein Board noch auf meiner Testplatte befindet, nur ein Handgriff.

Hat jemand vllt noch ne andere idee?


Habe auch schon daran gedacht mich mit meinem Problem an Roland zu wenden. Ich habe nur etwas skrupel ihn mit so einer Lapalie zu nerven.

Grüße
Tom

Wenn du die Beschleuningung auf z.B. 50 runtersetzt und sich die Achse langsam bremst, dann ist da wohl eher nen Bug drinne. Das wäre sicherlich dann interessant für Roland.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Okay, dann werde ich das heute abend nochmal sorgfälltig testen und Rückmeldung geben.

Edit:
Habe es nochmal langsamer getestet, das gleiche problem.
Ich werde jetzt eine PN an Repetier senden.

Gruß
Tom

1-mal bearbeitet. Zuletzt am 22.09.15 11:40.

Zum verständis. Diese Motorroutinen sind für einfache routinearbeiten wie abröumen oder extruderwechsel. Sie funktionieren nur wenn der normaller pfadplanner leer ist, aber das wird automatisch gemacht durch warten. Hier können auch neue Treiberhinzugefügt werden, aber ich gehe mal davon aus das hier der einzige verhandene Treiber verwendet wurde. In driver.h ist der gesamte code für die positionierung wo die stops auftreten:

    void gotoPosition(float newPos)
    {
        enable();
        int32_t target = floor(newPos * stepsPerMM + 0.5f) - position;
        position += target;
        if(target > 0) {
            HAL::digitalWrite(dirPin, !invertDir);
        } else {
            target = -target;
            HAL::digitalWrite(dirPin, invertDir);
        }
        while(target) {
            HAL::digitalWrite(stepPin, HIGH);
            HAL::delayMicroseconds(delayUS);
            HAL::digitalWrite(stepPin, LOW);
            HAL::delayMicroseconds(delayUS);
            target--;
            HAL::pingWatchdog();
            if((target & 127) == 0)
                Commands::checkForPeriodicalActions(false);
        }
    }

Was man klar sieht ist das alle 128 schritte Commands::checkForPeriodicalActions(false); aufgerufen wird und ansonsten nur der schrittmotor an und aus geht. In dieser routine wird die Temperatur gesteuert, was wiederum nur alle 0.1s geschieht, ansonsten sollte da nichts groß anfallen. Wenn es also softwareseitig ist muss es von dieser zeile kommen. Also im Zweifelsfall mit dem if davor auskommentieren aber dann kalt probieren oder sicherstellen das es ein kurzer move ist.

Die Geschwindigkeit ist übrigens mm/sekunde und nicht pro minute die du einstellst. Also versucht er da mit 120Khz sich zu bewegen.Beschleunigung gibt es nicht. Geschwindigkeit muss einfach konstant erreichbar sein bei dem Treiber.

Wenn du 300mm bewegst müstest du eigentlich messen können ob du schritte wegen überhitzung etc. verlierst. Dann schaffst du nämlich die 300mm nicht. Kommt er bei 300mm an sind die pausen softwarebedingt, e.b. display update (grafikdisplays brauchen 0.1sekunden zum updaten, 4x20 sind da deutlich schneller). Auch die werden in dieser routine glaube ich abgearbeitet. Da der Motor ja langsam bewegt sollten die stops an sich nicht stören, wenn man einmal weiß warum sie da sind. Das Temperaturupdate ist eher kurz und sollte kaum auffallen.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Da sich hier ja offensichtlich die Entwickler selbst mit meinem Problem beschäftigen hab ich natürlich alles was geschrieben wurde gleiche getestet.

Getestet wurde (um einen Hardware defekt aus zuschließen) wieder mit 3 unterschiedlichen Motoren (Nema17 nackig, Nema17 mit Trapezgewindespindel, Nema23 nackig) und 3 unterschiedlichen DRV Treibern.

Leider sind die Stops wieder regelmäßig vorhanden, egal ob mit 5 mm/s oder mit 40 mm/s. Der zurückgelegte Weg wurde mehrmals mit einem kalibrierten Mitutoyo Messschieber überprüft und für richtig befunden, Schrittverlust ist also unwarscheinlich. Ein überhitzen der Treiber ist ebenfalls unwarscheinlich da 2 Lüfter aufs Rumba Blasen, einer davon direkt auf den "Hilfsmotortreiber". Was sich allerdings unter dem aufgeklebten Kühlkörper abspielt kann ich leider nicht zuverlässig messen.
Das Ausklammern in der Drivers.h an der genannten Stelle brachte keine Veränderung.

Was könnte ich noch probieren? Ich bin bereit alles (soweit es meine Mittel zulassen) notwendige zu testen!

Danke schonmal bis hierher.

Gruß Tom

Hallo zusammen,

leider bin ich mit dem Problem noch immer nicht weiter.
Da der Schlitten durch den "Sichtbereich" fähren soll stört mich das ruckeln doch arg . Ein weiteres Problem ist das ich kein Beispiel finde wie man einen Referenzschalter mit dieser Funktion verknüpft um sicher zu stellen das der Schlitten vor Druckbegin nichtmehr im Weg steht.

Ein anderer Lösungsansatz der mir immer wieder durch den Kopf schießt ist die Verwendung eines Modellbau Servos. Die haben aber nur einen recht eingeschränkten Drehwinkel, die Ansteuerung wäre dagegen genial einfach. Unter den Windeservos (sollen scheinbar bis zu 10 umdrehungen zulassen) hab ich allerdings noch nichts in meinem gewünschten Preis/leistungsrahmen gefunden.

Im Repetier config tool wird darauf hingewiesen das sowohl Stepper als auch DC motor verwendbar ist. Bei der variante sind aber zwei Endschalter unabdingbar um einen crash zu vermeiden. Leider findet man Zur PWM variante noch viel weniger im Netz.

Gruß
Tom

Hast du mal einen anderen Treibertyp ausprobiert? Die DRV-Treiber haben ein etwas "anspruchsvolles" Timing. Da müssen an der ein oder anderen Stelle noch Delays verwendet werden, damit die anständig arbeiten. Andere Treiber sind da genügsamer.

Vielleicht hilft dir das ja.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Du must aufpassen. Die Driver Klasse ist eine allgemeine Schnittstelle die von den Befehlen verwendet wird. Ja nach Einsatzzweck must du aber selber eine solche Klasse ableiten. Als Demo ist ein einfacher Schrittmotorteiber ohne extras bereits vorhanden. Wenn du endschalter brauchst, must du so was ähnliches programmieren nur mit einem endschalter Test noch dazu. Also mache Schritt wenn Endschalter = low. Dann kannst du immer ganz dreist die volle Strecke fahren und der Endstop stoppt ihn dann schon. Was du im config tool ja angibst ist die initalisierung der gewählten ECHTEN klasse, also die, die es so macht wie du es gerne hättest. So gesehen kannst du das auch auf einfache Motoren umschreiben die dann einfach laufen bis zum endstop, egal wie weit du das eingegeben hast.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Ach ja noch was. Ganz ruhig werden die nie laufen, da sie nicht im interrupt angesteuert werden. Jeder interrupt fügt so seine extra Zeit dazu. Nie viel aber bei höherem tempo sind das dann schnell merkbare Hakler. Um die wegzubekommen müsste man das in einen Interrupt reinbekommen.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!