Software Schrittverluste?

Jetzt bin ich auch mal so richtig ratlos :




Bei 2 Teilen hintereinander tritt das gezeigte Problem exakt reproduzierbar auf. Die Schrittverschiebung (mit 99% Sicherheit keine Schrittverluste) tritt nur bei jeder 2ten Ebene auf und ist exakt unter 45° ausgerichtet.
Firmware: Marlin (verwende ich für PLA, da schneller als Repetier. In ABS mit Repetier hat das Teil funktioniert).
Drucker: H-Belt (könnte das Problem sein?)
Slicer: Skeinforge (Ergebnis ist laut Vorschau richtig, also ohne Versatz)

Hat jemand eine Idee?

LG, Willy

... wenn es wirklich nichts mechanisches ist, dann sollte das Problem bei den Anfangs- und Endkoordinaten der Kreise zu suchen sein - bei den Linien ohne Bögen im unteren Teil gibts ja auch keinen Versatz ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Scheint ja eindeutig die Firmware zu sein. Ich würde mal nur einen Holzylinder versuchen und gucken ob das da auch passiert.
Da ist bestimmt ein Bug in der Steuerung von dem H-Belt.
Wenndem so ist, können dir die Jungs die an der Firmware arbeiten bestimmt helfen.

---

Mfg
Wolfgang

Aller Anfang war schwer - Wolfstrap

Reprap-fab.org

Erfahrungen kann man leider schlecht weiter geben, die muss man selber machen.

Hallo Willy,

ich habe nur PLA und Repetier als FW - solche Probleme kenne ich nicht.

Wo ist Marlin denn schneller / vorteilhafter für PLA ?

vieleicht rutscht doch ein pulley auf der motorwelle?
gruss hd

Mechanische Probleme sind sehr, sehr unwahrscheinlich, da bei dem Aufsatz die Cool-Bremse zuschlägt (auf min. 10 s pro Layer eingestellt), was dazu führt, dass der Druck viel langsamer wird als im unteren Teil. Außerdem habe ich das Teil zwischenzeitlich erfolgreich mit Repetier gedruckt, wobei ich versucht habe, alle Marlin-Werte zu übernehmen.

@Jack_n: Zunächst einmal hat Repetier einen Wurzel-2-Fehler zumindest beim H-Belt-System 2. Wenn 100 mm/s eingegeben sind, dann erfolgt der Druck mit 71 mm/s.

Außerdem habe ich bei hohen Travel-Geschwindigkeiten (400 mm/s) teilweise Schrittverluste gehabt, wobei mein Eindruck war, dass zuviel verbrauchte Rechenzeit (für die Pfad-Planung?) beim Bewegen wieder ausgeglichen werden sollte und so zuviele Schritte auf einmal gemacht wurden. Dies ist aber nur eine Vermutung. Mit Marlin traten bei derselben gcode-Datei keine Schrittverluste auf. Dafür gibt es jetzt Probleme beim ganz langsamen Druck (s.o.).

LG, Willy

---

3D gedruckter Messerschärfer +++ RADDS für den Arduino-Due +++ Meine Drucker

Hast Du Roland über diesen Umstand Informiert?
Ich denke er kann die Fehlerhafte Feedrate ohne weiteres korregieren.

Viele Grüße
Joachim

Der Wurzel-2 Fehler ist in der development version behoben, auch wenn es nicht immer wurzel 2 ist. Bei diagonalen war das Tempo richtig. Dennoch solltet ihr immer berücksichtigen, das berechnungen auf die schritte der motoren sind und nicht auf das kartesische system. Für die Zielgeschwindigkeit habe ich das korrigiert, aber die Beschleunigungen beziehen sich nach wie vor auf die Motoren und nicht den kartesischen Weg.

Was die Schrittverluste angeht stellt sich die Frage, ob die die Geschwindigkeiten in Repetier durch 1,41 geteilt hast zum vergleichen. Wie gesagt der Faktor hängt vom Winkel ab. Ansonsten kannst du auch eine Verzögerung zwischen den Schritten für Doppelschritte einfügen, falls Repetier zu schnell ist.
#define DOUBLE_STEP_DELAY 1 // time in us

Ich gehe ja mal davon aus, das du bei 400mm/s deutlich über der Geschwindigkeit von 12000Hz liegst und daher die schritte verdoppelt oder vervierfacht werden müssen. Daher auch checken ob
#define ALLOW_QUADSTEPPING true
gesetzt ist.

---

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!

Hallo

beim Airtripper drucken habe ich dies auch.
Anstatt ne glatte Fläche zu machen baut er mir ne Wurst nach oben auf. (Bei der hinteren rechten Ecke wo die Schraube durch soll)

www.thingiverse.com/download:68866

Hängt es auch damit zusammen?

@repetier:

In der Tat habe ich die Messung bei x-Bewegungen vorgenommen, also nicht diagonal. Aber jetzt wird mir auch klar, warum kleine Kreise so "ruckelig" gefahren wurden - weil die Diagonalen schneller gedruckt wurden. Danke für die Änderung.

Wenn sich die Beschleunigungen auf die Motoren beziehen, mit welcher Beschleunigung rechnet denn dann der advance-Algorithmus?

Bei 80 Steps/mm und 400 mm/s ergeben sich 32000 Hz - also ist QUADSTEPPING prinzipiell erforderlich und war anfangs auch erlaubt. Ich hatte es dann auch mal abgeschaltet, was aber keine Verbesserung brachte. Was passiert eigentlich, wenn der Arduino zu langsam rechnet und zur Einhaltung der Geschwindigkeitsvorgabe z.B. noch 50 Schritte "sofort" gemacht werden müssten. Werden diese 50 Schritte dann quasi im Prozessortakt rausgehauen oder findet sich das Programm mit der Verzögerung ab und gibt die fehlenden Schritte mit der Geschwindigkeitsvorgabe aus?

Mit dem DOUBLE_STEP_DELAY muss ich wohl mal spielen.

LG, Willy

Willy Wrote:
-------------------------------------------------------
> @repetier:
>
> In der Tat habe ich die Messung bei x-Bewegungen
> vorgenommen, also nicht diagonal. Aber jetzt wird
> mir auch klar, warum kleine Kreise so "ruckelig"
> gefahren wurden - weil die Diagonalen schneller
> gedruckt wurden. Danke für die Änderung.
>

Ja, daran habe ich nicht gedacht als ich es eingebaut habe. Und ohne Ducker muss man mir so was halt sagen :-)

> Wenn sich die Beschleunigungen auf die Motoren
> beziehen, mit welcher Beschleunigung rechnet denn
> dann der advance-Algorithmus?

Die Beschleunigung mag zwar unterschiedlich sein, aber die gesamte linie ist linear genau wie die Anpassung beim advance, dass solte also passen.

>
> Bei 80 Steps/mm und 400 mm/s ergeben sich 32000 Hz
> - also ist QUADSTEPPING prinzipiell erforderlich
> und war anfangs auch erlaubt. Ich hatte es dann
> auch mal abgeschaltet, was aber keine Verbesserung
> brachte. Was passiert eigentlich, wenn der Arduino
> zu langsam rechnet und zur Einhaltung der
> Geschwindigkeitsvorgabe z.B. noch 50 Schritte
> "sofort" gemacht werden müssten. Werden diese 50
> Schritte dann quasi im Prozessortakt rausgehauen
> oder findet sich das Programm mit der Verzögerung
> ab und gibt die fehlenden Schritte mit der
> Geschwindigkeitsvorgabe aus?

Wenn das tempo nicht erreicht werden kann, wird der interrupt so schnell wie möglich wieder aufgerufen. Das ist dann nicht mehr ganz so gleichmäßig aber das beste was möglich ist. Es kommt also nicht zu einer plötzlichen Geschwindigkeitsänderung aber timing ist nicht mehr super präzise und langsamer als geplant. Bis 40 KHz sollte das aber nicht vorkommen. Aber da beim Quadstepping 4 schnelle schritte gefolgt von einem langen schritt gefolgt werden, ist der Motor schon arg gefordert. Mit dem delay wird die Pause zwischen den schnellen schritten erhöht, aber leider auch die ausführungszeit im interrupt.

---

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!