Druckprobleme seit Marlin Update

Hallo Zusammen,

ich habe vor kurzem meinen Drucker von Marlin 2.0.x (ich glaube zumindest, dass es so versioniert war) auf 2.0.9.3 geupdated, da ich ohnehin ein paar Einstellungen in der Firmware ändern musste (z.B. BTT Smart-Filament Sensor).
Leider hat sich das Druckbild des Drucker dadurch erheblich verschlechtert. und auch das Homing klappt das eine oder andere mal nicht.
(Ich würde aber nicht soweit gehen einen Hardware-Defekt auszuschließen, daher mal im Forum "Allgemeines" untergebracht.)
Den Filament-Sensor hab ich übrigens zu Fehlersuche direkt wieder ausgebaut - das Problem ist leider geblieben...

Es handelt sich um einen Delta mit SKR1.4T an einem Raspi mit Repetier-Server.

Seit dem Update druckt er Rundungen mit vertikalen Riffeln (Wellen). Gerade Linien macht er fast so gut wie zuvor.
Dazu habe ich mir mal ein Testteil gedruckt. Hatte gerade Flex-Filament drinnen und hab es deutlich zu heiß gedruckt, daher sieht der Druck sehr bescheiden aus, aber ich denke das Problem ist zu erkennen.
Die Spitzen des Dreiecks zeigen beim Druck genau auf die drei Delta-Türme und das Teil liegt genau in der Bett-Mitte.
Das Teil hat die besagten Wellen. Ich würde sagen diese sind davon abhängig, in welcher Achsenrichtung die Rundung überwiegend verläuft (daher hab ich auch ein Dreieck gedruckt um Achsen-Effekte zu sehen) und welchen Radius die Krümmung hat. Ich habe mal die Wellen-Abstände vermessen und dazu geschrieben.



die beiden anderen Seiten sehen Wellenfrei aus:




Hier ein anderes Teil, das eigentlich mit optimalen Filament-Parametern gedruckt wurde. Ebenfalls mit Wellen:


Und hier nur als Beweis, das der Drucker auch mal anders konnte:


Welche Einstellung kann das beeinflussen? Wie kann es sein, dass das nur in der einen Richtung passiert?
Das die Wellen Rundungsabhängig sind klingt für mich nach Software-Konfigurationsproblemen. Dass es nur in einer der drei Drei Richtungen zu sehen ist kann sowohl Software, als auch Hardware sein.
Welche Einstellung kann das beeinflussen? An welchen Parametern sollte ich mal rumprobieren?

1-mal bearbeitet. Zuletzt am 05.04.22 07:35.

Ich habs nochmal mit normalem Filament und den dazu passenden Einstellungen gedruckt.
Vielleicht siehts mans so besser.

Einmal von Oben (schlechte Seite rechts oben im Bild):

Die zu X parallele Seite mit diversen Wellenmustern:

Die beiden anderen Seiten sehen sehr gut aus (zumindest nach meinem Maßstab...):

Und einmal der Übergang zwischen den beiden Guten seiten - Stellenweise mit zu X parallelem Verlauf - und entprechend wieder wellig:


Gern auch nur Vermutungen äußern! Ich hänge schon 2 Wochen mit dem Problem an und tappe echt im Dunkeln....

Also nochmal ein Gedanke von mir dazu:
Ein Delta hat ja auch auf einer Geraden immer alle drei Türme in Bewegung - also sollte es ihm mechanisch doch herzlich egal sein, ob er gerade eine Gerade oder einen sanften Bogen fährt!?
Spricht also eher für ein Software Problem?

Ich komm auch langsam nicht mehr mit welche Parameter eigentlich für ihn wann gelten.
Ich kann ja Beschleunigungen, Geschwindigkeiten und Jerks mittlerweile an 3 Stellen konfigurieren:
1. In der Firmware - konfigurierbar im EEPROM (da gehört e meiner Meinung auch als einziges hin)
2. Im Repetier-Server (Ist es hier vielleicht nur zur Druckzeit-Berechnung oder hat es noch Einfluss aufs Drucken?)
3. Im G-Code (aktuellste Version vom Prusa-Slicer) (Hier hab ichs bisher ignoriert - Slic3er hats ja auch so geschafft zu Slicen...)

Versuch doch nochmal die vorherige funktionierende Marlin Version.
Hatte mit dieser Marlin-Version auch schon Schwierigkeiten mit dem SKR1.4 Turbo ist einfach im längeren Druck stehen geblieben, Heizung lief dabei weiter und war nicht mehr ansprechbar.
Allerdings habe keinen Delta Drucker, denke es könnte da ein Speicher/Buffer lesen/schreiben Problem geben.
Hab seitdem auf Klipper umgestellt und keine Probleme mehr.
Klipper (in meinem Fall MainsailOS) ist übrigens viel einfacher mit der Konfiguration und Einstellung der Raspi steuert ja das ganze und man muß nicht ständig in der Firmware etwas anpassen, kompilieren und aufspielen..

Danke für den Tipp,

habe glücklicherweise alle kompilierten Firmwares als Backups aufbewahrt. SO konnte ich was Marlin angeht sehr einfach auf einen alten Stand zurückkehren.
Leider hat das aber nicht geholfen.

Nun versuche ich gerade auf einen alten Repetier-Server Stand zurück zu kehren. Den habe ich nämlich zeitglich mit Marlin geupdated - rückblickend eine blöde Idee so viel auf einmal zu ändern...

Das gestaltet sich aber deutlich schwieriger als ich erwartet hatte. Während mit Balena Etcher sehr einfach Images auf eine SD-Karte Spielen kann. Ist ein Backup mit dieser Software - meines Wissens - nicht ohne weiteres möglich.

Daher hab ich ein Programm namens "SD_DiskImage_1_6_WinAll" benutzt, das beide Partitionen einzeln gesichert hat, statt die Komplette SD-Karte auf einmal auszulesen.
Jetzt bekomme ich die Partitionen nicht so einfach wieder drauf geschrieben.
(Keine Ahnung warum ich diesmal nicht Win32-Disk-Imager für Backup verwendet hatte.)

Ich hab es nach ungefähr 5 Anläufen endlich geschafft ein altes Image auf die SD-Karte zu flashen. (der hat irgendwie dauernd eine Image Datei auf die komplette SD-Karte geschrieben, statt etwas Platz für die zweite "Hälfte" zu lassen...)

Das blöde ist, selbst mit dem Marlin und Repetier-Server-Backup-Images ist der Fehler nach wie vor da.
Mit dem Image druckt er deutlich langsamer als mit dem zuvor aktuellsten Stand (weil ich damals noch nicht so viel Geschwindigkeit rausgekitzelt hatte). Das Druckbild ist aber nahezu identisch.

Ich habe jetzt versuchsweise mal alle 3 Schrittmotoren und die zugehörigen Endstops eine Position weiter Rotiert um zu schauen, ob der Fehler mit wandert oder an selber Stelle bleibt.

Ergebnis: Der Fehler hat sich mit gedreht. Das heißt also Motoren-Kabel, Motoren und Mechanik sind in Ordnung!

Damit bleiben sowohl die Software, al auch das SKR1,4 Board samt Treiber als Fehlerursache über.

Als nächsten Schritt werde ich mal die Treiber durchtauschen und sehen, ob der Fehler wieder mit wandert.

Wenn das erfolglos bleibt muss ich versuchen in der Software die Motoren inklusive Treiber einer anderen Achse zuzuordnen.
Wenn da jemand Erfahrung hat kann er hier gern schonmal schreiben wie man das macht. (geht das in configuration.h oder configuration.adv.h oder eher in der pins_BTT_SKR_V1_4.h?)

1-mal bearbeitet. Zuletzt am 09.04.22 09:37.

So,
ich habe die Motoren und Endstops auf ihre alte Positionen gesteckt und dafür aber die Shrittmotor-Treiber um eine Position weiter rotiert.
Die Wellige Seitewar nun wieder auf ihrer ursprünglichen Position.
Also sind es auch nicht die Treiber.

Nun bleiben noch das SKR-Mainboard und die Software als mögliche Fehlerquelle übrig.

Kann mir jemand sagen, wie ich die Motor-Ausgang Zuordnung zu den Achsen ändern kann?

Muss ich nur in diesem Block in der pins_BTT_SKR_V1_4.h was vertauschen (und anschließend entsprechen wieder Kabel so vertauschen, dass Endstop- und Motoren-Ausgänge zueinander passen)?
Ich habe TMC2209 Treiber.

//
// Steppers
//
#define X_STEP_PIN                         P2_02
#define X_DIR_PIN                          P2_06
#define X_ENABLE_PIN                       P2_01
#ifndef X_CS_PIN
  #define X_CS_PIN                         P1_10
#endif

#define Y_STEP_PIN                         P0_19
#define Y_DIR_PIN                          P0_20
#define Y_ENABLE_PIN                       P2_08
#ifndef Y_CS_PIN
  #define Y_CS_PIN                         P1_09
#endif

#define Z_STEP_PIN                         P0_22
#define Z_DIR_PIN                          P2_11
#define Z_ENABLE_PIN                       P0_21
#ifndef Z_CS_PIN
  #define Z_CS_PIN                         P1_08
#endif

#define E0_STEP_PIN                        P2_13
#define E0_DIR_PIN                         P0_11
#define E0_ENABLE_PIN                      P2_12
#ifndef E0_CS_PIN
  #define E0_CS_PIN                        P1_04
#endif

#define E1_STEP_PIN                        P1_15
#define E1_DIR_PIN                         P1_14
#define E1_ENABLE_PIN                      P1_16
#ifndef E1_CS_PIN
  #define E1_CS_PIN                        P1_01
#endif

#define TEMP_1_PIN                      P0_23_A0  // A0 (T0) - (67) - TEMP_1_PIN
#define TEMP_BED_PIN                    P0_25_A2  // A2 (T2) - (69) - TEMP_BED_PIN

z.B. so:

//
// Steppers
//
#define X_STEP_PIN                         P0_22
#define X_DIR_PIN                          P2_11
#define X_ENABLE_PIN                       P0_21
#ifndef X_CS_PIN
  #define X_CS_PIN                         P1_08
#endif

#define Y_STEP_PIN                         P2_02
#define Y_DIR_PIN                          P2_06
#define Y_ENABLE_PIN                       P2_01
#ifndef Y_CS_PIN
  #define Y_CS_PIN                         P1_10
#endif

#define Z_STEP_PIN                         P0_19
#define Z_DIR_PIN                          P0_20
#define Z_ENABLE_PIN                       P2_08
#ifndef Z_CS_PIN
  #define Z_CS_PIN                         P1_09
#endif

#define E0_STEP_PIN                        P2_13
#define E0_DIR_PIN                         P0_11
#define E0_ENABLE_PIN                      P2_12
#ifndef E0_CS_PIN
  #define E0_CS_PIN                        P1_04
#endif

#define E1_STEP_PIN                        P1_15
#define E1_DIR_PIN                         P1_14
#define E1_ENABLE_PIN                      P1_16
#ifndef E1_CS_PIN
  #define E1_CS_PIN                        P1_01
#endif

#define TEMP_1_PIN                      P0_23_A0  // A0 (T0) - (67) - TEMP_1_PIN
#define TEMP_BED_PIN                    P0_25_A2  // A2 (T2) - (69) - TEMP_BED_PIN

Mangels Feedbacks hab ichs einfach mal ausprobiert, was ich zuletzt geschrieben habe und es so umgesetzt:

//
// Steppers
//
#if 0   // Auswahlmoeglichkeit die Stepper Ausgaenge fuer Fehlersuche zu drehen

//normal
#define X_STEP_PIN                         P2_02
#define X_DIR_PIN                          P2_06
#define X_ENABLE_PIN                       P2_01
#ifndef X_CS_PIN
  #define X_CS_PIN                         P1_10
#endif

#define Y_STEP_PIN                         P0_19
#define Y_DIR_PIN                          P0_20
#define Y_ENABLE_PIN                       P2_08
#ifndef Y_CS_PIN
  #define Y_CS_PIN                         P1_09
#endif

#define Z_STEP_PIN                         P0_22
#define Z_DIR_PIN                          P2_11
#define Z_ENABLE_PIN                       P0_21
#ifndef Z_CS_PIN
  #define Z_CS_PIN                         P1_08
#endif

#else

//gedreht
#define X_STEP_PIN                         P0_22
#define X_DIR_PIN                          P2_11
#define X_ENABLE_PIN                       P0_21
#ifndef X_CS_PIN
  #define X_CS_PIN                         P1_08
#endif

#define Y_STEP_PIN                         P2_02
#define Y_DIR_PIN                          P2_06
#define Y_ENABLE_PIN                       P2_01
#ifndef Y_CS_PIN
  #define Y_CS_PIN                         P1_10
#endif

#define Z_STEP_PIN                         P0_19
#define Z_DIR_PIN                          P0_20
#define Z_ENABLE_PIN                       P2_08
#ifndef Z_CS_PIN
  #define Z_CS_PIN                         P1_09
#endif

#endif

Hat aber leider nicht funktioniert.
Die drei Türme homen sich zwar auf befehl, wenn dann aber eine Bewegung erfolgen soll bewegen sich nur zwei von dreien.
Und jedes Anfahren der Achsen wird von kurzem (Bruchteil einer Sekunde) Rattern begleitet, das ich noch nicht so richtig einordnen kann. Überspringen der Zahnriemen kann es eigentlich nicht sein - klingt aber sehr ähnlich.

Wäre echt cool, wenn mir jemand aus diesem Forum helfen könnte.

1-mal bearbeitet. Zuletzt am 10.04.22 06:59.