Z_SAVE_HOMING überspringt Schritte

Diskussionen Rund um die Firmware eurer 3D Druckerer wie Marlin, Skynet, Repetier etc.
Antworten
Anton_39
Neuling
Beiträge: 6
Registriert: So 25. Aug 2019, 01:32
Wohnort: Deutschland
Drucker: mgn Cube
Slicer: Cura
Firmware: Marlin 2.0
CAD - Software: Fusion360
Hat sich bedankt: 0
Danksagung erhalten: 0

Z_SAVE_HOMING überspringt Schritte

#1

Beitrag von Anton_39 » So 25. Aug 2019, 02:13

Gute Nacht allerseits,
ich baue gerade den mgn Cube von Ben Levi (Thingiverse). Es handelt sich bei meinem Drucker um einen CoreXY Drucker. Verbaut sind:
SKR v1.3
DRV8825
0,9 Grad Stepper
24V
BlTouch
und der restliche "normale" Kram.
Der Drucker funktioniert in meinen ersten Tests sehr gut. Alles scheint gut zu funktionieren. Wenn ich allerdings z save homing aktiviere um mit dem BlTouch in der Mitte des Hotbets zu messen, gibt der Drucker nur ein relativ hohes Geräusch von sich und der Druckkopf bewegt sich unkontrolliert ein wenig durch die Gegend. Das heißt er kommt mit der Beschleunigung nicht zurecht.

Als erstes habe ich die Spannung der Treiber auf 1v erhöht und es tritt keine Verbesserung ein. Der Drucker wird allerdings signifikant lauter.
Danach habe ich nach ein ander alle Geschwindigkeiten, Beschleunigungen und Jerk in der Firmware auf ein Minimum reduziert. Das hatte zur Folge, dass alle Bewegungen AUßER der einen Bewegung von z save homig super langsam waren. Ich habe alles was ich finden konnte reduziert.
Ich habe 12V und 24V versucht ohne Besserung.

Ich habe nicht mehr viele Ideen wie ich das Problem lösen könnte. Aber die paar liste ich auf, vielleicht habt ihr ja auch welche.
1. will ich sowie so machen und bringt vielleicht nichts TMC2208 für X und Y Motor.
2. Ich glaube das Problem kommt daher, dass für diese Diagonale Bewegung nur ein Motor verantwortlich ist (coreXY). Wenn jemand weiß wie ich die Beschleunigung und Jerk Werte nicht für die Achsen, sondern für die Motoren einstellen kann würde das vielleicht helfen.
3. Hat jemand eine Idee wie man die Geschwindigkeit für diesen eine Bewegung verändern kann (vielleicht im G-code vor dem Homen und danach wieder zurücksetzen)
4. habe ich die Stelle in Marlin 2.0 einfach nicht gefunden wo man die Werte verändern kann? (bitte auch Tipps für Marlin 1.x die helfen bestimmt auch)

Falls ich irgendetwas übersehen haben sollte bitte schreiben, bei Fragen zum System einfach fragen. Ansonsten bitte ich um etwas Nachsicht, ich bin das erste Mal im Forum unterwegs. Ich freue mich über alle konstruktiven Antworten. Vielen Dank für eure Hilfe und erstmal eine gute Nacht.

Benutzeravatar
th33xitus
Admin
Beiträge: 3555
Registriert: Sa 17. Dez 2016, 00:31
Drucker: AM8
Slicer: PrusaSlicer
Firmware: Marlin-bugfix-2.0.x
CAD - Software: Fusion 360
Hat sich bedankt: 142 Mal
Danksagung erhalten: 455 Mal

#2

Beitrag von th33xitus » So 25. Aug 2019, 09:09

Moin, willkommen hier bei uns ;)

Bei Fragen zur Firmware und Konfigurationen wäre es immer von Vorteil direkt die verwendeten Configuration.h und Configuration_adv.h Dateien mit anzufügen. Wie das geht hatte ich hier mal beschrieben: viewtopic.php?f=37&t=3673

So Aussagen wir "alle Bewegungen außer der einen" sind immer schlecht. Woher soll man nun wissen welche der Bewegungen du nun meinst?
Blinder Aktionismus bringt übrigens in den meisten Fällen ebenso wenig etwas ;)

Zu 2: Was genau versprichst du dir davon, den Jerk pro Motor einstellen zu können und nicht pro Achse? (was afaik nicht möglich ist, außer evtl. bei den Z-Motoren)

Zu 3: HOMING_FEEDRATE_XY legt die Geschwindigkeit fürs Homing der X- und Y-Achse fest.

Anton_39
Neuling
Beiträge: 6
Registriert: So 25. Aug 2019, 01:32
Wohnort: Deutschland
Drucker: mgn Cube
Slicer: Cura
Firmware: Marlin 2.0
CAD - Software: Fusion360
Hat sich bedankt: 0
Danksagung erhalten: 0

#3

Beitrag von Anton_39 » So 25. Aug 2019, 12:50

Guten Morgen,
das Ganze zieht sich schon sehr lange hin, von Aktionismus kann da nicht die Rede sein. im März hatte ich ein Rramps Bord mit einem Arduino. Die Problematik war die gleiche, außer dass der Extruder Motor nicht funktionierte. Nach einigem Fehlersuchen habe ich das China Ramps Modul als schuldig befunden und, dass ein Arduino für coreXY etwas schwach auf der Brust ist, ein SKR v1.3 Bestellt. Das ist im Juli angekommen und seitdem versuche ich Schritt für Schritt das Problem zu lösen.

Die Dateien habe ich angehängt und ein Video, dass das Problem zeigt ist unter http://sendvid.com/xtbtmsz6 zu finden.

zu 2: bei einem coreXY Setup werden die diagonalen Bewegungen ja von einem Motor gemacht. Dieser eine Motor beschleunigt nun sowohl die x als auch die y-Achse und ist dadurch doppelt belastet, während der andere Motor nur steht. Deshalb erscheint es mir sinnvoll die Beschleunigungen und Jerk Werte bei coreXY nicht für die Achsen, sondern für die Motoren festzulegen, da die Bewegungen von den Motoren nicht direkt zu den Bewegungen der Achsen passen.

zu 3: das habe ich bereits deutlich gesenkt (kann man auch im Video sehen), diese Einstellung scheint aber nicht für die Bewegung in die Mitte zu gelten denn es tritt keine Veränderung ein.

Viele Grüße,
Anton
Dateianhänge
Configuration.h
(75.68 KiB) 5-mal heruntergeladen
Configuration_adv.h
(87.72 KiB) 4-mal heruntergeladen

Benutzeravatar
th33xitus
Admin
Beiträge: 3555
Registriert: Sa 17. Dez 2016, 00:31
Drucker: AM8
Slicer: PrusaSlicer
Firmware: Marlin-bugfix-2.0.x
CAD - Software: Fusion 360
Hat sich bedankt: 142 Mal
Danksagung erhalten: 455 Mal

#4

Beitrag von th33xitus » So 25. Aug 2019, 14:11

Mal allgemein Dinge die mir so auffallen... von oben nach unten durch die Configs:

Code: Alles auswählen

#define PREVENT_COLD_EXTRUSION
#define EXTRUDE_MINTEMP -15
Um die Funktion korrekt zu deaktivieren setzt man vor jedes "#define" ein "//".
Das ist eleganter als die MINTEMP auf -15°C zu setzen und hat den gleichen Effekt.

Code: Alles auswählen

/**
 * Stepper Drivers
 *
 * These settings allow Marlin to tune stepper driver timing and enable advanced options for
 * stepper drivers that support them. You may also override timing options in Configuration_adv.h.
 *
 * A4988 is assumed for unspecified drivers.
 *
 * Options: A4988, A5984, DRV8825, LV8729, L6470, TB6560, TB6600, TMC2100,
 *          TMC2130, TMC2130_STANDALONE, TMC2208, TMC2208_STANDALONE,
 *          TMC26X,  TMC26X_STANDALONE,  TMC2660, TMC2660_STANDALONE,
 *          TMC2160, TMC2160_STANDALONE, TMC5130, TMC5130_STANDALONE,
 *          TMC5160, TMC5160_STANDALONE
 * :['A4988', 'A5984', 'DRV8825', 'LV8729', 'L6470', 'TB6560', 'TB6600', 'TMC2100', 'TMC2130', 'TMC2130_STANDALONE', 'TMC2160', 'TMC2160_STANDALONE', 'TMC2208', 'TMC2208_STANDALONE', 'TMC26X', 'TMC26X_STANDALONE', 'TMC2660', 'TMC2660_STANDALONE', 'TMC5130', 'TMC5130_STANDALONE', 'TMC5160', 'TMC5160_STANDALONE']
 */
//#define X_DRIVER_TYPE  DRV8825
//#define Y_DRIVER_TYPE  DRV8825
//#define Z_DRIVER_TYPE  DRV8825
//#define X2_DRIVER_TYPE A4988
//#define Y2_DRIVER_TYPE A4988
//#define Z2_DRIVER_TYPE A4988
//#define Z3_DRIVER_TYPE A4988
//#define E0_DRIVER_TYPE DRV8825
//#define E1_DRIVER_TYPE A4988
//#define E2_DRIVER_TYPE A4988
//#define E3_DRIVER_TYPE A4988
//#define E4_DRIVER_TYPE A4988
//#define E5_DRIVER_TYPE A4988
Du solltest, wenn du schon den Treiber-Typ in der Configuration.h bestimmt, die dazugehörigen Zeilen auch aktivieren.
Auskommentiert bringt dir das rein garnüscht :P

Code: Alles auswählen

/**
 * Default Axis Steps Per Unit (steps/mm)
 * Override with M92
 *                                      X, Y, Z, E0 [, E1[, E2[, E3[, E4[, E5]]]]]
 */
#define DEFAULT_AXIS_STEPS_PER_UNIT   { 400, 400, 3200, 588 }

/**
 * Default Max Feed Rate (mm/s)
 * Override with M203
 *                                      X, Y, Z, E0 [, E1[, E2[, E3[, E4[, E5]]]]]
 */
#define DEFAULT_MAX_FEEDRATE          { 300, 300, 20, 25 }

/**
 * Default Max Acceleration (change/s) change = mm/s
 * (Maximum start speed for accelerated moves)
 * Override with M201
 *                                      X, Y, Z, E0 [, E1[, E2[, E3[, E4[, E5]]]]]
 */
#define DEFAULT_MAX_ACCELERATION      { 1000, 1000, 50, 10000 }

/**
 * Default Acceleration (change/s) change = mm/s
 * Override with M204
 *
 *   M204 P    Acceleration
 *   M204 R    Retract Acceleration
 *   M204 T    Travel Acceleration
 */
#define DEFAULT_ACCELERATION          1000    // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION  2000    // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION   1000    // X, Y, Z acceleration for travel (non printing) moves

/**
 * Default Jerk (mm/s)
 * Override with M205 X Y Z E
 *
 * "Jerk" specifies the minimum speed change that requires acceleration.
 * When changing speed and direction, if the difference is less than the
 * value set here, it may happen instantaneously.
 */
#if DISABLED(JUNCTION_DEVIATION)
  #define DEFAULT_XJERK 10.0
  #define DEFAULT_YJERK 10.0
  #define DEFAULT_ZJERK  0.3
#endif

#define DEFAULT_EJERK    5.0  // May be used by Linear Advance
Das sind insgesamt nun keine ungewöhnlichen Werte die du da angegeben hast. Feedrates und Accelerations sind human, für einen CoreXY sogar echt tief gegriffen in meinen Augen. Das sind so Werte wie ich sie auf meinem Bettschubser verwende und der schmeißt ja immerhin das schwere Heizbett hin und her.

Jetzt nun eine Frage:
Passiert das nur beim Homing? Oder kannst du generell keine solch schnellen Bewegungen an den Drucker senden?
Wenn ich nicht daneben liege, dann sollte diese Passage hier jetzt dafür zuständig sein, dass nach dem X und Y Endstop-Anschlag der Druckkopf schnell in die Mitte des Bettes gefahren wird. Also genau die Sequenz die dir Probleme bereitet:

Code: Alles auswählen

// X and Y axis travel speed (mm/m) between probes
#define XY_PROBE_SPEED 8000
8000mm/m entsprechen ~ 133mm/s.
Das sollte EIGENTLICH locker machbar sein wenn die Mechanik mitspielt.

Code: Alles auswählen

// Homing speeds (mm/m)
#define HOMING_FEEDRATE_XY (50*40)
#define HOMING_FEEDRATE_Z  (4*40)
Was ist das denn für eine komische Angabe der Homing-Geschwindigkeiten?
In der Regel steht dort in den Klammern ( X *60). Die 60 zu verändern macht insofern absolut keinen Sinn weil man es sich damit nur selbst unnötig schwer macht die exakte Geschwindigkeit einzutragen. Die "60" sind im Endeffekt die automatische Umrechnung in mm/s.
Du hast da jetzt also 2000mm/m stehen, was 33,33333 mm/s entspricht.
Wenn das so gewollt ist, könntest du auch einfach (33*60) schreiben und machst es damit dir und jedem der deine Configs überprüfen soll einfacher und erspart unnötige Umrechnungen ;) Aber das nur nebenbei.


Also... ich vermute einfach es liegt an der Kombination aus DRV8825 und den 0,9° Steppern.
Die Jumper fürs 32er Microstepping sind ja alle korrekt gesetzt oder?
Schau dann mal ob auch andere Travel-Moves davon betroffen sind indem du die per G-code den Druckkopf zum Test mal mit 8000mm/m in die ein oder andere Richtung schickst. Eventuell die Software-Endstops deaktivieren, sodass du nicht ständig zum Homing gezwungen wirst was ja eh nicht gescheit klappt.

Anton_39
Neuling
Beiträge: 6
Registriert: So 25. Aug 2019, 01:32
Wohnort: Deutschland
Drucker: mgn Cube
Slicer: Cura
Firmware: Marlin 2.0
CAD - Software: Fusion360
Hat sich bedankt: 0
Danksagung erhalten: 0

#5

Beitrag von Anton_39 » So 25. Aug 2019, 15:27

Vielen dank für die Mühe und die schnelle Antwort.
Das probiere ich gleich mal aus. Ich habe schon einen Kalibration Cube gedruckt, das war kein Problem. Auch andre Bewegungen waren ok.
Ich glaube das Problem kommt daher, dass die beiden Beschleunigungen für X- und Y-Achse von einem Motor gemacht werden und sich dadurch verdoppeln (ich meine, dass das auch für den Jerk gilt) und das macht der einfach nicht mit.
Meinst du, dass dich das Problem mit TMC2208 oder TMC2209 beheben ließe? Oder hast du noch andrer Treiber im Sinn dafür? Die müssen auch nicht unbedingt besonders leise sein, der Drucker steht in einem Haus, das normaler weise nur als Abstellkammer dient.
Mit dem Microstepping hatte ich auch schon Probleme. Ich habe das so gelöst, dass ich die Pins oben auf dem Stepper zusammengelötet habe, das hat funktioniert. Die homing Bewegung funktioniert auch wenn ich die Spannung des Treibers so richtig hochdrehe. Einen Treiber habe ich auch schon Kaput gespielt. Jetzt habe ich keinen mehr zur Sicherheit.
Viele Grüße,
Anton

Benutzeravatar
th33xitus
Admin
Beiträge: 3555
Registriert: Sa 17. Dez 2016, 00:31
Drucker: AM8
Slicer: PrusaSlicer
Firmware: Marlin-bugfix-2.0.x
CAD - Software: Fusion 360
Hat sich bedankt: 142 Mal
Danksagung erhalten: 455 Mal

#6

Beitrag von th33xitus » So 25. Aug 2019, 15:58

Anton_39 hat geschrieben:
So 25. Aug 2019, 15:27
Auch andre Bewegungen waren ok.
Und was waren nun diese "andre Bewegungen" ?
Ich hab ja eine explizite Frage nach Bewegungen mit einer Geschwindigkeit von 8000mm/m gefragt.
Anton_39 hat geschrieben:
So 25. Aug 2019, 15:27
Ich glaube das Problem kommt daher, dass die beiden Beschleunigungen für X- und Y-Achse von einem Motor gemacht werden und sich dadurch verdoppeln (ich meine, dass das auch für den Jerk gilt) und das macht der einfach nicht mit.
Wie kommst du denn auf solche Annahmen?
Anton_39 hat geschrieben:
So 25. Aug 2019, 15:27
Meinst du, dass dich das Problem mit TMC2208 oder TMC2209 beheben ließe? Oder hast du noch andrer Treiber im Sinn dafür?
Bevor ich zu irgendwelchen Treibern rate, würde mich überhaupt viel eher erst mal interessieren was deine Beweggründe waren die dich dazu geführt haben zu 0,9°-Motoren und DRV8825 Treibern zu greifen. Was ist deine Absicht damit?
Anton_39 hat geschrieben:
So 25. Aug 2019, 15:27
Mit dem Microstepping hatte ich auch schon Probleme. Ich habe das so gelöst, dass ich die Pins oben auf dem Stepper zusammengelötet habe, das hat funktioniert.
Und wie hat sich das geäußert?
"die Pins" sind dann jetzt welche Pins genau?
Anton_39 hat geschrieben:
So 25. Aug 2019, 15:27
Die homing Bewegung funktioniert auch wenn ich die Spannung des Treibers so richtig hochdrehe.
WELCHE Homing Bewegung? Homing ist ne Sequenz aus mehreren Bewegungen...
Und wie hoch ist "so richtig hoch"? Werd doch mal präzise bitte...
Das ist wieder genau so unpräzise wie in deinem ersten Beitrag das "alle Bewegungen außer der einen" funktionieren.
Wir brauchen hier klare Kommunikation... hier hat niemand Lust auf Rätsel raten und wildes spekulieren was nun genau gemeint sein kann bringt niemandem etwas. Nicht wir sitzen vor deinem Gerät sondern nur du allein... damit haben wir hier schon mal ein um ein vielfach schwereres "Leben" wenn man dir hier helfen will.



EDIT:
Unabhängig von all dem wäre es vielleicht auch angebracht mal die Riemen korrekt zu verbauen und nicht so verdreht wie du sie da verbaut hast:
2019-08-25_16-04.png

Benutzeravatar
Bill Dung
Unterstützer
Beiträge: 734
Registriert: Mo 6. Mär 2017, 12:01
Wohnort: Spreenhagen
Drucker: AM8, BDE, Tante R
Slicer: Simplify3D
Firmware: Marlin 2, Repetier
CAD - Software: OpenSCAD, Fusion 360
Hat sich bedankt: 52 Mal
Danksagung erhalten: 99 Mal

#7

Beitrag von Bill Dung » So 25. Aug 2019, 16:10

Wenn ich mich nicht ganz irre, ist das Verdrehen der Riemen beim BLV MGN so vorgesehen.

Edith hat nachgeschaut, kein muss, aber so vom Entwickler bevorzugt.
Zynismus ist der geglückte Versuch, die Welt zu sehen, wie sie wirklich ist.

Müll kann man nicht trennen, der hat nur eine Silbe.

Benutzeravatar
th33xitus
Admin
Beiträge: 3555
Registriert: Sa 17. Dez 2016, 00:31
Drucker: AM8
Slicer: PrusaSlicer
Firmware: Marlin-bugfix-2.0.x
CAD - Software: Fusion 360
Hat sich bedankt: 142 Mal
Danksagung erhalten: 455 Mal

#8

Beitrag von th33xitus » So 25. Aug 2019, 16:18

Habe auch gerade nochmal nachgeschaut und es ist laut Entwickler "optional" (nicht bevorzugt): https://cdn.thingiverse.com/renders/5a/ ... _large.jpg

Naja... gut. Soll auch nicht zum Hauptpunkt der Diskussion werden. ICH persönlich würde es jedenfalls nicht so verbauen.

Benutzeravatar
Bill Dung
Unterstützer
Beiträge: 734
Registriert: Mo 6. Mär 2017, 12:01
Wohnort: Spreenhagen
Drucker: AM8, BDE, Tante R
Slicer: Simplify3D
Firmware: Marlin 2, Repetier
CAD - Software: OpenSCAD, Fusion 360
Hat sich bedankt: 52 Mal
Danksagung erhalten: 99 Mal

#9

Beitrag von Bill Dung » So 25. Aug 2019, 16:19

Er schreibt drunter " I prefer this option + flipping the belts". Der Drucker hat ein paar nette Ideen, zum Beispiel die Integration der Motoren in die Umlenkung und damit verbundenen die einfache Möglichkeit zum Spannen der Riemen. Andersrum sind zu viele Druckteile notwendig, die absolute Präzision erfordern, da summieren sich kleine Fehler schnell.

Und nun zurück zum Thema ;)
Zuletzt geändert von Bill Dung am So 25. Aug 2019, 16:25, insgesamt 1-mal geändert.
Zynismus ist der geglückte Versuch, die Welt zu sehen, wie sie wirklich ist.

Müll kann man nicht trennen, der hat nur eine Silbe.

Benutzeravatar
th33xitus
Admin
Beiträge: 3555
Registriert: Sa 17. Dez 2016, 00:31
Drucker: AM8
Slicer: PrusaSlicer
Firmware: Marlin-bugfix-2.0.x
CAD - Software: Fusion 360
Hat sich bedankt: 142 Mal
Danksagung erhalten: 455 Mal

#10

Beitrag von th33xitus » So 25. Aug 2019, 16:24

Okay... durch die ganze Beschreibung hab ich mich nicht durchgescrollt. Ich hab die Bilder oben auf der Seite durchgeswitcht...
Naja dann ist das wohl so "richtig" ;)

Anton_39
Neuling
Beiträge: 6
Registriert: So 25. Aug 2019, 01:32
Wohnort: Deutschland
Drucker: mgn Cube
Slicer: Cura
Firmware: Marlin 2.0
CAD - Software: Fusion360
Hat sich bedankt: 0
Danksagung erhalten: 0

#11

Beitrag von Anton_39 » So 25. Aug 2019, 16:34

Im testdruck, mit 80 mm/s waren die eingestellten travel Bewegungen auch kein Problem. Außerdem funktioniert das homen der X- und Y-Achse auch mit 8000mm/m. nur die Bewegung danach (Video) funktioniert nicht.

Ich komme auf diese Annahme, weil für diagonale Bewegungen nur ein Motor verwendet wird. Und dieser muss dann beide Achsen gleichzeitig beschleunigen.
(https://www.youtube.com/watch?v=7jMiMZ3TOqM)

Die Motoren habe ich wegen der höheren Auflösung gekauft und die DRV8825 hatte ich noch da. Für die Treiber gibt es keine Absicht.

Natürlich die Pins, die für das microstepping verantwortlich sind (M 0, M 1, M 2). Das Problem war, das ich scheinbar nur 16 microstepps hatte und keine 32.

Es geht um die einzige Bewegung, die nicht funktioniert (Video). Bei 1.34v geht es. Aber eben nur einmal, dann war der Treiber futsch. Da half auch der Lüfter und der Kühlkörper nicht.

Bei den Aktuellen 0,93 V funktioniert die Bewegung nicht (Video).

Benutzeravatar
th33xitus
Admin
Beiträge: 3555
Registriert: Sa 17. Dez 2016, 00:31
Drucker: AM8
Slicer: PrusaSlicer
Firmware: Marlin-bugfix-2.0.x
CAD - Software: Fusion 360
Hat sich bedankt: 142 Mal
Danksagung erhalten: 455 Mal

#12

Beitrag von th33xitus » So 25. Aug 2019, 17:40

Im testdruck, mit 80 mm/s waren die eingestellten travel Bewegungen auch kein Problem.
:roll:

Ich weiß durchaus wie die Bewegungen in einem CoreXY System zustande kommen. Sonst würde ich mich hier zurückhalten und nix zu einem Thema sagen von dem ich nicht weiß wie es funktioniert, aber danke für das Video. Kenne ich zwar bereits aber erklärt es ganz gut.

Eine logische Bewegung des Druckkopfes wäre jetzt natürlich eine diagonale Bewegung mit F8000 gewesen ;) Hast du das gemacht?
Du hast ja bereits festgestellt, dass Bewegungen mit F8000 scheinbar funktionieren wenn BEIDE Motoren dazu aktiv werden.
Und dann schauen wir mal ob ein Motor alleine auch andere diagonale Bewegungen mit der Geschwindigkeit hinbekommt oder eben nicht.
Und dieser muss dann beide Achsen gleichzeitig beschleunigen.
Und dann nimmst du an, dass EIN Motor alleine dann mit einer doppelt so hohen Beschleunigung und einem doppelt so hohen Ruck arbeiten muss wenn dieser den Druckkopf in der Diagonalen mit derselben Geschwindigkeit bewegen soll die sonst auch mit 2 Motoren gefahren wird? Klingt das nicht für dich selbst ein wenig unlogisch?

Anton_39
Neuling
Beiträge: 6
Registriert: So 25. Aug 2019, 01:32
Wohnort: Deutschland
Drucker: mgn Cube
Slicer: Cura
Firmware: Marlin 2.0
CAD - Software: Fusion360
Hat sich bedankt: 0
Danksagung erhalten: 0

#13

Beitrag von Anton_39 » So 25. Aug 2019, 22:11

Ich habe nun mal getestet, wo die Limits bei den verschiedenen Bewegungsrichtungen liegen.
Bei einer Bewegung bei denen beide Motoren aktiv sind ist ungefähr bei 10000mm/m Schluss.
Bei einer diagonalen Bewegung dagegen schon bei ca. 6400mm/m.

th33xitus hat geschrieben:
So 25. Aug 2019, 17:40
Und dann nimmst du an, dass EIN Motor alleine dann mit einer doppelt so hohen Beschleunigung und einem doppelt so hohen Ruck arbeiten muss wenn dieser den Druckkopf in der Diagonalen mit derselben Geschwindigkeit bewegen soll die sonst auch mit 2 Motoren gefahren wird? Klingt das nicht für dich selbst ein wenig unlogisch?
Nein, eigentlich nicht. Oder hast du eine bessere Erklärung dafür? Der Motor beschleunigt im Falle der Diagonalen Bewegung zwei Achsen. Mir scheint es so, als würden die Beschleunigungen und der Ruck dann einfach addiert. Auch die Maximal möglichen Geschwindigkeiten verdoppeln sich mit einem sehr dicken Daumen. Und das kann ein Motor alleine dann nicht leisten. Gibt es denn keine Möglichkeit die Beschleunigung und den Maximalen Ruck der Motoren einzeln zu begrenzen?
Allerdings hast du recht das DRV8825 und 0,9 Grad Stepper keine gute Kombi sind. Das ist a.) sehr laut, und b.) scheint das Drehmoment nicht besonders hoch zu sein.
Hast du denn eine Idee wie man dem fehlenden Drehmoment Herr werden kann? Ich habe eigentlich nicht die Absicht 1.8° grad Stepper zu verbauen. Wenn kein weg darum führt, mache ich es aber lieber, als meinen Drucker nur Langsam zu betreiben. Viel lieber wäre mir einen anderen Treiber zu verwenden. Ich weiß nur nicht welcher sich da am besten eignet.
Morgen werde ich mal die Beschleunigungen und Geschwindigkeiten in der Firmware anpassen, und schauen ob es dann funktioniert.

Im Anhang befindet sich mein hochgradig professioneller Test Gcode.
Dateianhänge
diagonal test.gcode
(893 Bytes) 1-mal heruntergeladen
normal test.gcode
(770 Bytes) 2-mal heruntergeladen

Benutzeravatar
stranger1971
Neuling
Beiträge: 37
Registriert: Di 12. Jun 2018, 19:07
Wohnort: Kempten
Drucker: mehr als einer
Slicer: Simplify3D
Firmware: Marlin 2.0
CAD - Software: Cinema4D
Hat sich bedankt: 0
Danksagung erhalten: 2 Mal

#14

Beitrag von stranger1971 » So 25. Aug 2019, 22:37

Hi,

Da muss ich dem Chef Recht geben. Für mich ist es auch unlogisch.
Du fährst nur in eine Richtung. ,nämlich eine gerade Diagonale!
Bei CoreXY sind halt die Bewegungsrichtungen um 45 Grad versetzt und sonst gar nix.
Klingt für mich eher wie ein mechanisches Problem.
Die andere Diagonale funktioniert? Man sitzt halt nicht davor.

Gruß Alex

Gesendet von meinem SM-N910F mit Tapatalk


Benutzeravatar
th33xitus
Admin
Beiträge: 3555
Registriert: Sa 17. Dez 2016, 00:31
Drucker: AM8
Slicer: PrusaSlicer
Firmware: Marlin-bugfix-2.0.x
CAD - Software: Fusion 360
Hat sich bedankt: 142 Mal
Danksagung erhalten: 455 Mal

#15

Beitrag von th33xitus » Mo 26. Aug 2019, 00:48

Anton_39 hat geschrieben:
So 25. Aug 2019, 22:11
Bei einer Bewegung bei denen beide Motoren aktiv sind ist ungefähr bei 10000mm/m Schluss.
Bei einer diagonalen Bewegung dagegen schon bei ca. 6400mm/m.
Das sind also ~167mm/s mit zwei Motoren bzw ~107mm/s mit einem Motor.
Das lässt für mich also Grund zur Annahme, dass die Firmware hier also weder ein Limit setzt, noch anderweitig die Beschleunigungswerte beeinflusst wenn in einer CoreXY-Konfiguration nur einer von zwei Motoren verwendet wird um Bewegungen auszuführen. Würde sie das tun, so würde ich zumindest eine klares Verhältnis von Motoranzahl zu Geschwindigkeit bei sonst fixen Parametern erwarten. -> (1/2) != (6400/10000) ; ergo -> Haben wir hier nicht.

Um die Annahme zu verifizieren habe ich jedoch mal eine Frage an die Entwickler gestellt und warte auf Antwort ob dies bestätigt werden kann. Sobald ich da was vorzeigbares erhalte werde ich das hier natürlich nachreichen.
Anton_39 hat geschrieben:
So 25. Aug 2019, 22:11
Oder hast du eine bessere Erklärung dafür?
Joa... solange eben die oben von mir getroffene Annahme von den Entwicklern weder bestätigt noch widerlegt wurde, ist meine Erklärung die Physik.
Warum soll es bei einem Motor die doppelte (in der Firmware festgelegte) Beschleunigung brauchen um eine fixe Masse in gleicher Zeit auf eine definierte Geschwindigkeit v zu beschleunigen? Das ergibt keinen Sinn wenn man sich allein schon vor Augen führt wie die Beschleunigung überhaupt definiert ist.

Ich weiß nicht wie du zu deinen Annahmen kommst, sie sind für mich einfach nicht logisch nachzuvollziehen.


Wo ich aber komplett bei dir bin ist folgende Aussage:
Anton_39 hat geschrieben:
So 25. Aug 2019, 22:11
Und das kann ein Motor alleine dann nicht leisten.
Und das ist eigentlich auch der springende Punkt denke ich...
Das was wir hier haben ist zu großer Wahrscheinlichkeit KEIN Problem mit der Firmware. Es ist schlicht ein Problem mit der Hardware.
0,9° Schrittmotoren und dann 1/32 Microstepping. Du kastrierst das eh schon im Vergleich (oft) geringere Drehmoment eines 0,9° Schrittmotors mit dem 1/32 Microstepping ins "unermessliche".
Anton_39 hat geschrieben:
So 25. Aug 2019, 22:11
Ich habe eigentlich nicht die Absicht 1.8° grad Stepper zu verbauen. Wenn kein weg darum führt, mache ich es aber lieber, als meinen Drucker nur Langsam zu betreiben. Viel lieber wäre mir einen anderen Treiber zu verwenden.
Naja... ohne die genaue Bezeichnung deiner momentanen Stepper nun zu kennen, sind für die Absicht "schnell" 0,9° Stepper nicht der richtige Ansatz.
Wäre die Absicht nun "langsam und präzise", dann ja. Daher ist meine persönliche Empfehlung nun sicher schon klar.
Du kannst natürlich nun mal versuchen die DRV8825 in 1/16 oder 1/8 Microstepping zu betreiben. Vielleicht bringt das was. Aber sichern sein würde ich mir da nun nicht.

Anton_39
Neuling
Beiträge: 6
Registriert: So 25. Aug 2019, 01:32
Wohnort: Deutschland
Drucker: mgn Cube
Slicer: Cura
Firmware: Marlin 2.0
CAD - Software: Fusion360
Hat sich bedankt: 0
Danksagung erhalten: 0

#16

Beitrag von Anton_39 » Mo 26. Aug 2019, 15:52

Ich verwende diese Stepper für X- und Y-Achse https://www.ebay.de/itm/0-9deg-Nema-17- ... Swg-tb9mIj

Benutzeravatar
th33xitus
Admin
Beiträge: 3555
Registriert: Sa 17. Dez 2016, 00:31
Drucker: AM8
Slicer: PrusaSlicer
Firmware: Marlin-bugfix-2.0.x
CAD - Software: Fusion 360
Hat sich bedankt: 142 Mal
Danksagung erhalten: 455 Mal

#17

Beitrag von th33xitus » Mo 26. Aug 2019, 17:06

Und was für eine Antwort erwartest du nun jetzt? Denkst du ernsthaft ich äußere mich jetzt zu deinen Motoren wenn du einfach hier nun herkommst und den Link hier hin klatschst?

Hast du überhaupt begriffen wofür ich mir die Mühe gemacht habe um es dir zu erklären? Oder ist dir das jetzt egal und du ignorierst es weil ich dir vielleicht Aufgezeigt habe, dass deine Erklärungen unlogisch sind und es einfach nicht so klappt wie du es dir initial bei dem Bau des Druckers vorgestellt hast?

Benutzeravatar
Bill Dung
Unterstützer
Beiträge: 734
Registriert: Mo 6. Mär 2017, 12:01
Wohnort: Spreenhagen
Drucker: AM8, BDE, Tante R
Slicer: Simplify3D
Firmware: Marlin 2, Repetier
CAD - Software: OpenSCAD, Fusion 360
Hat sich bedankt: 52 Mal
Danksagung erhalten: 99 Mal

#18

Beitrag von Bill Dung » Mo 26. Aug 2019, 17:12

Frei nach Goethe: Die Botschaft hört er wohl, allein der Glaube fehlt ihm.
Zynismus ist der geglückte Versuch, die Welt zu sehen, wie sie wirklich ist.

Müll kann man nicht trennen, der hat nur eine Silbe.

Benutzeravatar
riff-raff
Moderator
Beiträge: 912
Registriert: Do 19. Apr 2018, 14:35
Wohnort: Leipzig
Drucker: ANET A8, CoreXY
Slicer: Prusa Slic3r
Firmware: Marlin 2.0-bugfix
CAD - Software: F360, Inv, SW
Hat sich bedankt: 34 Mal
Danksagung erhalten: 83 Mal

#19

Beitrag von riff-raff » Fr 18. Okt 2019, 09:44

Ich fleddere hier mal die Thread-Leiche weil ich gerad drüber gestolpert bin.

Ähnliche Probleme, dass bei bestimmten Bewegungsrichtungen massive Schrittverluste zu beobachten sind habe ich auch gemacht:
Hier nachzulesen

Ich hatte ebenfalls die Motoren im Verdacht, dann die Treiber, dann das Board.
Es ließ sich aufs SKR eingrenzen, aber: beim Invertieren der Achsorientierung für X und Y war das Problem nicht mehr zu beobachten.

Evtl. mal testen.
Chaos is found in greatest abundance wherever order is being sought.
It always defeats order, because it is better organized.
Terry Pratchett

Antworten
  • Vergleichbare Themen
    Antworten
    Zugriffe
    Letzter Beitrag