The max Z speed should be honored as a whole for XYZ moves. I remember that not working right, but I thought they fixed it. Basically, a move from 0 to 100,100,1 Should be able to finish in 1 second if the max speeds are 100,100,1. Disregarding accelerations, and the F on it would need to be about 140.
Yeah I am pretty sure it works again. We had the accels way down at one point, like 5 so on a 3D or a bunch of clearance plane move sit was really noticeable.
I’ve updated from 412 to 414 and in the configuration I’m seeing Junction is now 0.1 instead of 0.01, so that should be a big help. I did a video before and after and I am still seeing sluggish behavior around arcs. I used the crown svg and Estlcam with a feed rate of 720 mm/min, aiming for the same 12 mm/sec as the official test gcode.
Here is before, version 412:
And after, version 414:
In both cases the movement queue was not being depleted so I don’t think it’s a CPU issue.
I ported over my personal preferences which I don’t think are relevant to this test, but I’ll list everything in case:
- #define MOTHERBOARD BOARD_MKS_GEN_L
- #define USE_ZMAX_PLUG
- #define X_MIN_ENDSTOP_INVERTING false
- #define Y_MIN_ENDSTOP_INVERTING false
- #define Z_MIN_ENDSTOP_INVERTING false
- //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
- #define Z_MIN_PROBE_PIN Z_MIN_PIN
- #define FIX_MOUNTED_PROBE
- #define Z_MIN_PROBE_REPEATABILITY_TEST
- #define Z_HOME_DIR 1
- #define NUM_SERVOS 4
- #define SERVO_DELAY { 300, 300, 300, 300 }
And in Configuration_adv.h:
- #define BEZIER_CURVE_SUPPORT
- #define G38_PROBE_TARGET
- #define G38_PROBE_AWAY
- #define JOYSTICK
- #define JOYSTICK_DEBUG
- #define MAX7219_DEBUG
- #define MAX7219_CLK_PIN 42
- #define MAX7219_DIN_PIN 63
- #define MAX7219_LOAD_PIN 40
I’m going to try disabling S_CURVE_ACCELERATION and ADAPTIVE_STEP_SMOOTHING. If neither makes a difference then I’ll try increasing JUNCTION_DEVIATION to a “crazy” value and see what happens and then after that who knows. Maybe I’ll try classic jerk just to see. Maybe I’ll play with arc parameters and see what happens. Or see how much of a difference the acceleration values have.
1 Like
Crud. That is crazy that does not seem like arcs are an issue it makes all the small circles fine it seems like corners tighter than 90 are triggering that to choke it. but they both seem bad to me.
I will put my MP back together this afternoon and run it. I would say jump up to 415 (linked at the top) that gets us to 2.01 at least. I did the math on the junction deviation, there are two links in the firmware but maybe my test file doesn’t trigger it. But that seems to be the issue for sure. I will make a few test crowns.
Ok I’ll upgrade to 415. I had hesitated because I’m on RAMPS-like but I’ll give it a shot. Good news is that 415 contains a joystick fix that came after 412 and 414.
Also I found that disabling S_CURVE_ACCELERATION and ADAPTIVE_STEP_SMOOTHING didn’t make a difference, or not enough of a difference that I could tell.
Also here is the gcode I generated, if you want to try to reproduce the behavior exactly.
0102_crown_mine.gcode (I have a lift and pause at the beginning which is when I normally turn the tool on.)
1 Like
Fantastic! 415 solved the slow arcs. 
Along the way I noticed that the steppers are set back to A4988 in 415 with steps/mm to match. I set it back to DRV8825 with 200 steps per mm.
I also did M502 and M500 to reset any other settings just in case.
OctoPrint gives a warning about temperature protection when extruders is 0. I’ll probably submit a PR to upstream Marlin about this. (Done: Fix where Extruders == 0 is considered thermally unsafe by vector76 · Pull Request #16459 · MarlinFirmware/Marlin · GitHub)
1 Like
YESSSS!!! Did you do it they way I have with with everything not specified other than 0.3mm segments? Do you agree with that number or can/should we go lower?
The Rambo has A49 driver timing so it does not get changed. (I did up the current to 75% though).
Freaking sweet!
I will work on the other boards later then. That is great news.
1 Like
I tried re-enabling
#define MIN_ARC_SEGMENTS 5
#define N_ARC_CORRECTION 25
expecting to see the problems, but the same crown was fine with no slow arcs. I was really struggling to understand this then I realized the difference in MIN_ARC_SEGMENTS, which was 24 for version 414 and 5 for version 415. I tried setting MIN_ARC_SEGMENTS to 24 in version 415 and the slow arcs appeared again.
I have not yet tried lowering MM_PER_ARC_SEGMENT but it is becoming apparent that the length and number of arc segments is key to the slow arcs problem. Unfortunately it seems there would be a tradeoff: if you wanted to have a pen to have a high feedrate for tracing a large-radius curve, then a small value for MM_PER_ARC_SEGMENT could flood the system with a high rate of short segments, but for a slow small-radius helical plunge you would want smaller MM_PER_ARC_SEGMENT to faithfully reproduce a circle instead of a polygon. Perhaps the ideal MM_PER_ARC_SEGMENT would depend on feedrate and it would be better specified as MS_PER_ARC_SEGMENT to keep a roughly constant rate of segments going.
I think I will try this: first change MM_PER_ARC_SEGMENT to lower values and see if I can get sluggish arcs. Then generate gcode with faster feedrates and see if it gets sluggish at the same point or if it gets sluggish with relatively longer MM_PER_ARC_SEGMENT. Maybe I might look at MS_PER_ARC_SEGMENT but no promises.
Well I just ran these with both of those settings commented out, in hopes of letting them set themselves? That seems to work great.
Sorry it is a bit messy. look at the word “engineering” at the bottom of each letter. There is zero accelerations happening and it is slamming. The difference between them is Junction deviation set to 0.2, 0.016, 0.008, 0.002. There seemed to be zero difference between them. The accels for that in general do not seem right. If you look at the concentric circles, the smallest two run stupid fast, the rest seem to have accels happening.
This test file ran like actual dog poop on 414, almost perfect on the 415. If you run it I have the pen offset the thickness of a paper business card when I hit start.
Arc Torture test.gcode (24.8 KB)
Arc Torture test.zip (20.4 KB)
1 Like
The plot thickens!
With JD still on, I tried with no S curve, then with no adaptive…no change. I then tried Classic Jerk at 1,1,0.3, great…a bit too slow though. Went up to 5,5,0.3 small details were flawless, I mean just how you want to see it move, but as the moves got larger it would almost speed up slow down and speed up again, super wonky. So on the concentric circles the first three were great but the next three would have that weird arc issue almost but would instead accel and decel twice per circle.
So…
I am going to mess with the actual accelerations.
150-200 looks like what I imagine for our speeds
Okay after a ton of brute force attempts and trials. I like 230 for accels and a JD of 0.045, still not convinced of this thing working but that is the calc.
I swear there is a (-) sign missing from the junction deviation equations or something. Smaller radius are most certainly accelerating faster and larger ones are much slower.
Not sure what is in this torture test, but I was going to recommend a tiny square with larger and larger offsets to make larger and larger arcs.
You can see them on the paper. Tiny letters all rounded, offset ovals, circles, and squished square for sharp corners.
Have you seen a tool to show the Marlin output, log it or anything?
Which output? The serial log will just be a bunch of 'ok’s. You can log it in octoprint. I bet you can log it in repetier. Or pronsole.
I’m looking for like a way to see what the output of marlin is doing with the Gcode. After it goes through the plannner. I do not think JD is working right, but I also think If I could see the output I could get it real close and accurate instead of my current, edit, compile, flash, run, test cycle.
Setting the JD to .2 all the way down to .002 seemed no different at all in any way. I can tune the regular jerk and accelerations much more confidently.
Oh, you want to see the xy locations it is trying to follow?
Yeah, more speeds it is setting but that as well. I would love to be able to see both gcode and post planner at the same time!
Can we run the firmware in some sort of simulator or something?
I would like, as a permanent feature, to have the current speed on the lcd.
There is a configuration for a simulation machine. I haven’t looked at it though. Maybe @jamiek or @anttix would know.
It says it in the firmware notes, “nothing under 5mm radius”. So they know of the short comings but that makes it basically useless in my opinion.