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.)
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.
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.
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)
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.
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.
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.
Seeing the planner output is something I’ve wanted before too. When I increase the joystick position from slow to fast, it will momentarily slow down and then speed up. I am pretty confident my movement commands are not doing that, and I have no visibility into why the planner is doing that.
It looks like the simulation machine is to compile the thing as a Linux program and it looks like you can log the position trajectory over time. You would have to back out the segment trapezoids, if that’s even possible.
The gcode parser/interpreter does the vast majority of the calculation and inserts segments (called “blocks”) into the movement queue, and ISRs dequeue from the movement queue and manage the steppers. (This is why the queue not being depleted implies the 8-bit hamster wheel is keeping up with fancy gcode.)
When movements are inserted into the queue they can modify adjacent movements that are already in the queue, like forcing different acceleration if the start of the new movement is not compatible acceleration-wise with the end of the previous movement. This means it’s not enough to capture the segments as they are inserted into the queue. You have to capture them as they are coming out of the queue (or at least are not near the tail of the queue).
It’s not feasible to add serial diagnostic to the ISR that pulls from the head of the queue but perhaps there could be a mid-queue reporting feature that spews some segment information to the console…
Is it time to stop trying to bend Marlin to our will and just use GRBL? I am not concerned with printing anymore. large format printers are stupid cheap now so I don’t see any other need to use Marlin right?
