Hallo,

nachdem ich zwischenzeitlich dachte, dass mein Problem mit dem XY-Versatz gelöst wäre, musste ich jetzt leider feststellen, dass es nach wie vor besteht. Ich kann es jetzt allerdings besser beschreiben und dadurch vielleicht die ein oder andere Ursache ausschließen.

- der Versatz geht immer nach "hinten links"
- der Versatz tritt nicht nur beim Layerwechsel auf, sondern auch bei "Sprüngen" von einer Kontur zur nächsten
- die einzelnen Konturen an sich weisen keine Fehler auf
- die Druckgeschwindigkeit scheint keine Rolle zu spielen
- der Drucker verhält sich wie bei einem Schrittverlust, also fährt der Y-Schlitten beim Ausgeben des Objekts vorne auf Block. Die Achsen sind allerdings freigängig und einzelne Konturen werden, wie gesagt, ohne Fehler gedruckt.
- Beschleunigung X/Y: 1000
- Jerk: 12,5
- Motorstrom X/Y: 2,0 A (126)
- das Problem tritt beim Druck über USB und von der SD-Karte auf.

Das wichtigste allerdings:
- Mit FW-Version 1.41.20 (community_stable) habe ich das Problem nicht. Mit dieser Version hatte ich vorher lange Zeit problemlos gedruckt. Ich habe sie jetzt wieder auf den Drucker geladen und er druckt wieder wie gewohnt.

Hallo Timo,

ich kann es mir nicht vorstellen, dass dein Problem mit der FW zusammen hängt.
Sonst hätten noch mehr Leute Probleme damit.

Ich Tippe immer noch darauf, dass sich dein Motorritzel auf der Narbe verdreht.
Mache einfach mit einem guten Filzschreiber auf Ritzel samt Motorwelle eine Markierung.
Sollte sich da was verdrehen, dann hast du die Kontrolle darüber.

Dein Motorstrom ist zwar noch im Rahmen aber trotzdem schon hoch.
Standard Einstellungen für X und Y sind 110 und für Z 105.
Schaue auch nach einem längerem Druck nach deiner Motortemp.
Die sollte so an der Schmerzgrenze (60 C°) beim Anfassen sich befinden.

Hast du im Unterbett eine zweite Führungsschiene eingebaut?

LG AtlonXP

Hallo AtlonXP,

grundsätzlich stimme ich dir zu, dass ein Hardwarefehler bei mir naheliegender ist, wenn sonst niemand dieses Problem hat. Es ist allerdings auch nicht das erste Mal, dass mein Drucker sich zickiger anstellt als die Mehrzahl der RF2000. Ich hatte auch schon beim Heizbettscan das Problem, dass es am Ende zu einem Reset kam, wenn das Bett 10 mm nach unten gefahren ist. Nibbels hatte daraufhin eine Kleinigkeit modifiziert und seitdem funktioniert der Scan auch bei mir.

Den Test mit der Markierung an Welle und Ritzel werde ich aber natürlich trotzdem noch machen, nur um ganz sicher zu gehen.
Ich halte das aber für eher unwahrscheinlich, da der Versatz zu gleichmäßig/reproduzierbar ist, nicht innerhalb einer geschlossenen Kontur auftritt, nur in jeweils eine Richtung pro Achse wirkt und vor allem, da er nach dem Downgrade der FW bei identischen Slicer-Einstellungen unmittelbar verschwunden ist.

Die Motoren werden auch nach mehreren Stunden Druck immer nur gut handwarm. Ich messe gleich mal mit dem IR-Thermometer, sobald der aktuelle Druck beendet ist (geht noch bis ca. 9 Uhr).

Zweite Y-Schiene ist verbaut, daher habe ich den Strom auch etwas erhöht. In X-Richtung habe ich einen Zusatzlüfter und eine Extruder-Wakü eingebaut, daher habe ich auch dort den Strom erhöht. Die Wasserkühlung ist allerdings noch nicht in Betrieb.

Viele Grüße
Timo

trilobyte hat geschrieben: "21:34:47.543 : setupForPrinting(): invalid active heat bed z matrix detected: 13

EDIT: http://www.rf1000.de/viewtopic.php?f=4& ... +13#p23352 <- hier wars!

Ich muss mal nachsehen, wie das passieren kann. Ich habe den Fehler schonmal gehört, aber ich dachte eigentlich bei der original Firmware.
Da steht im EEPROM-Settings-Speicher eine Zahl 13 drin, die aber normalerweise nur 0 bis 9 sein darf.

Geh mal bitte im Menü auf Configuration -> Z-Configuration -> Matrix: xxx (Oder ähnlich, kann gerade nicht nachschauen)
Du musst die Auswahlnummer der Matrix einmal verstellen, sodass dort wieder eine Zahl 0 bis 9 drin steht.
Unter Umständen geht das auch übers EEPROM-Tool in Repetier-Host oder Repetier-Server.

Ich werde mir notieren, beim Laden einer Matrix darauf zu achten, dass dort wirklich 0..9 drin stehen muss. Notfalls kann ich ja alle EEPROM-Werte die nicht gültig sind einfach mit 0 überschreiben, sodass sich der Fehler automatisch löst.

LG

@Timo,
zu deiner zusätzlichen Y Schiene.

Ich könnte mir da noch Verspannungen vorstellen, weil die eine Schiene zur anderen doch geringe Abweichungen haben kann.
Bei meinem RF1000 hatte ich die Ausfräsungen für die Schienen vermessen.
Ich hatte dabei schon ein paar hundertstel Abweichungen festgestellt.

Das erklärt natürlich nicht eine Abweichung in X.
Viel mehr fällt mir zu deinem Problem leider nicht ein.

LG AtlonXP

Timo hat geschrieben:Hallo,

nachdem ich zwischenzeitlich dachte, dass mein Problem mit dem XY-Versatz gelöst wäre, musste ich jetzt leider feststellen, dass es nach wie vor besteht. Ich kann es jetzt allerdings besser beschreiben und dadurch vielleicht die ein oder andere Ursache ausschließen.

- der Versatz geht immer nach "hinten links"
- der Versatz tritt nicht nur beim Layerwechsel auf, sondern auch bei "Sprüngen" von einer Kontur zur nächsten
- die einzelnen Konturen an sich weisen keine Fehler auf
- die Druckgeschwindigkeit scheint keine Rolle zu spielen
- der Drucker verhält sich wie bei einem Schrittverlust, also fährt der Y-Schlitten beim Ausgeben des Objekts vorne auf Block. Die Achsen sind allerdings freigängig und einzelne Konturen werden, wie gesagt, ohne Fehler gedruckt.
- Beschleunigung X/Y: 1000
- Jerk: 12,5
- Motorstrom X/Y: 2,0 A (126)
- das Problem tritt beim Druck über USB und von der SD-Karte auf.

Das wichtigste allerdings:
- Mit FW-Version 1.41.20 (community_stable) habe ich das Problem nicht. Mit dieser Version hatte ich vorher lange Zeit problemlos gedruckt. Ich habe sie jetzt wieder auf den Drucker geladen und er druckt wieder wie gewohnt.

Für den Fall, dass du dringend die 1.41.20 wirklich nutzen willst, füge bitte den folgenden Sicherheitspatch in den Quellcode https://github.com/Nibbels/Repetier-Fir ... 4fa1ab4e0f ein.
Ohne diesen Patch ist die Firmware nicht sicher.

Allerdings kann ich dir evtl. noch einen Tipp geben:
Es gibt Beschleunigungen und Bewegungs-Maxima für "Print" und "Travel".
Ich vermute, dass du bei den Travel-Bewegungen vielleicht eine zu hohe Geschwindigkeit eingestellt hast, oder die Beschleunigung nicht mit < 2000 bzw. > 0 übereinstimmt.
Eine Null "0" bei den Beschleunigungen in unserer Firmware ist sehr schädlich. Damit läuft was gravierend falsch.

- Du kannst mir auch gerne einen Export deiner EEPROM-Einstellungen zuschicken, dann schaue ich mir kurz die Werte durch.
- Manchmal ist es auch so, dass im Startcode die Beschleunigungen überschrieben werden. Man sieht dann nicht direkt, dass die Beschleunigungen viel zu hoch eingestellt werden.
- Es könnte auch sein, dass das Ritzel nicht fest genug auf der Motorwelle sitzt. Das ist nicht immer offensichtlich, vorallem wenn man mit Schraubensicherungslack im Gewinde gearbeitet hatte. Man kann mit einem Edding einen Strich von der Welle nach aussen aufs Ritzel malen, dann sieht man schnell, ob die Welle sich gegens Ritzel verdreht hat.
- Prüfe bitte die Motor-Strom-Einstellungen und mach evtl. für eine "schwere Achse" einfach mal den Strom (= Moment) höher.

LG

Ich habe die EEPROM-Werte ausgelesen, die Beschleunigungen sehen mir aber alle unverdächtig aus.
Anschließend habe ich die 1.42.22 nochmal kompiliert und hochgeladen, um zu überprüfen, ob sich - warum auch immer - an den Werten etwas geändert hat. Ist aber alles gleich geblieben. An den Sourcen habe ich seit dem letzten Versuch nichts geändert.

Danach habe ich einfach nochmal das "Problemteil" von gestern mit den Einstellungen gedruckt, die gestern noch zum Fehler geführt haben. Diesmal war aber alles in Ordnung.

So richtig plausibel ist mir das nicht. Ich weiß jetzt weder, was das Problem verursacht hat, noch, wodurch es behoben wurde. Vielleicht waren zwischenzeitlich die Beschleunigungswerte im EEPROM auf 0 und wurden beim flashen der alten FW auf korrekte Werte gesetzt?

Ich werde die Sache auf jeden Fall weiter beobachten, aber vorerst sehe ich das Problem als gelöst an. Motorwellen und Ritzel sind jetzt jedenfalls markiert, falls der Fehler doch dadurch verursacht wurde.

Vielen Dank nochmal für die schnelle Hilfe und natürlich auch für die tolle Arbeit mit der Community-Firmware!

Edit: eine Kleinigkeit habe ich diesmal doch anders gemacht: beim letzten Mal habe ich die Arduino-Suite (1.8.7 x64) direkt auf dem Steuerrechner (Ubuntu) über X11-forwarding ausgeführt und die Suite auch für den Upload benutzt. Diesmal habe ich Arduino (1.8.5) an meinem normalen Rechner ausgeführt, die Hexdatei auf den Steuerrechner geladen und per avrdude aus der Kommandozeile hochgeladen. An sich sollte das aber doch nichts ausmachen?!

Danke für deine Rückmeldung

Eigentlich sollte das alles nichts ausmachen.
Das EEPROM fasse ich bei einem Upgrade normalerweise nicht an. Wenn sich da was ändern sollte, baue ich normalerweise "Update-Scripte" mit ein. Also z.B. Ziehe ich einen Wert komplett auf eine andere Adresse um, oder ich prüfe den bisherigen Wert, ob er noch zu der neuen Firmware passt und schreibe ihn notfalls auf Standard. Aber das kommt so gut nicht vor und in den letzten Versionen habe ich sowas nicht gemacht.

Wahrscheinlicher ist, dass sich beim Drucker was an der Temperatur geändert hat oder ein Krümelchen Filament nun nicht mehr blockiert ...
Doch bei einer Software die in C/C++ programmiert ist, will ich mich auch nicht zu weit aus dem Fenster lehnen - mit solchen Aussagen

In jedem Fall kann ich mir deinen Fall nicht erklären. Ich habe aber den Verdacht, dass irgendwas in deinem Drucker gerade so am Limit läuft.

LG

Ich muss mich auch mal zu wort melden. Ich habe gestern von der offiziellen 1.37er FW auf die aktuelle 1.42er Community FW umgestellt. An den Einstellungen habe ich ansonsten nichts verändert, jeweils die defaultwerte.
Die Beschleunigungswerte in der Community-FW sind scheinbar sanfter eingestellt (ich habe die alten vergleichswerte nichtmehr). Aber ab und an - je nach Objekt alle 1-2 Layer - gibt es einen bewegungsschritt, wo der Drucker jegliche Beschleunigungswerte ignoriert und die Bewegung sehr "hart" fährt - man hört das in dem moment und der ganze Tisch, auf dem der Drucker (RF 1000 übrigens) steht, ruckt bei mir einmal relativ stark. Versatz tritt dennoch nicht auf, aber es kann ja durchaus sein dass der ein oder andere Stepper hier nicht mitkommt? Es klingt jedenfalls nicht sehr gut und materialschonend ist das ganze sicher auch nicht.

Die gleichen Gcode-dateien mit der alten FW zeigte dieses Verhalten nicht. Habt ihr eine Idee was ich tun kann?

Übrigens: wo finde ich die originale Conrad-1.42er-Firmware? Oder gibt es die für den RF1000 gar nicht mehr?

Hallo rivadynamite,

es kann am RF1000 schon ein paar harte Schläge lassen.
Kannst du der Sache genauer nach gehen und berichten was da so klappert?
Bei mir war es der Retract und auch die Z Achse.

Da du nun die Comnity FW drauf hast, kann man vieles über das Druckermenü einstellen.

Ich glaube für den RF1000 ist die höchste originale FW 1.39
Ich meine die FW 1.42 ist nur für den RF2000 V2 gedacht.
Wenn es anders ist, dann bitte ich um Korrektur.


Mein RF1000 läuft Seiden weich.
Der Z- Lift scheint nun auch zu funzen!

LG AtlonXP