[BUG] Junction Deviation (enabled) causes curve stuttering #17920
Comments
|
Could you isolate a half/full circle of the gcode that stutters, and upload it? |
Here's a snippet: G1 X221.745 Y15.794 E9.0641 |
|
How fast did you print? |
|
Try it out: JD_single_arc_test_2.zip |
|
Gcode: Issue_17920.zip Speed limit profile (not accounting for The problem is, that we're just on the verge of 1 mm length on those segments. So we jump between regular >1 mm EDITED: Realized, that the segment length is the problem, not the junction angle (that's around 177.5° for most). |
|
See zipped video example. Also note blobby curves already on printbed. |
|
So we should come up with solution where transition between speeds will be smooth. What about get rid of 1mm block and >135° condition and do the math always? Maybe we can do it with another/faster approximation and without division at the end of calculation (I have this approximation on my github). But I'm just guessing - I don't understand the code and movement enough. |
|
Here's the block or segment length for the GCode in discussion: |
Dropping those if-checks sadly doesn't solve the stutter in this case. This is a general problem of the discretization and the fact that we can't look ahead. The two JD code paths ( There's only one way to safely prevent this: When planning a block, look ahead a couple of blocks to see where we are going. Then, fit an analytical function to our path (backwards and ahead) and calculate the second derivative for the block currently being planned. That would require extensive changes to the planner code and quite a bit of computational resources when running. Also, I wouldn't know how to implement this in C++ 😄 |
|
Should we revert back to classic jerk before the next release? |
|
I'm not sure if it is necessary to default back to classic jerk since for the most part JD is seems to work. Below my results with the jump from good to bad: Edit: Corrected the commit dates. |
It's preferable for many cases, so it might be the best choice for certain example configurations. However, this kind of suggestion implies that we are no closer to a solution. Since jerk is relatively inexpensive, perhaps the best thing would be a hybrid approach. Although, I am still curious to see if the "angular change within X total distance" accumulator approach could also work, insofar as it can be tracked in an efficient way. I feel I could get pretty far with this sort of algorithm experimentation if I had nothing else to do. I mean, what we ultimately want to do is produce the ideal and perfect, but horribly expensive version first. Then try to chop that up into something simpler. But maybe Classic Jerk is superior in every way? I can't think of too many reasons to fault it. |
@Lord-Quake — You may be right. Does it look better if you disable |
|
@thinkyhead Using commit 2020.05.04 I disabled
Result is no more stuttering. The print turned out fine. You've now got something to work with :-) |
|
Just for the sake of completeness I tried the latest commit 86c1125 and disabled I did find a new issue (cosmetics only though) |
|
Since #17938 has already been merged and might influence this, it would be nice if someone affected could check this again (with the lookup table enabled) using most recent bugfix. It may be improved, I don't think it will be fixed. |
|
Well testing with my Ender 3 Pro is over for now..... |
|
@XDA-Bam While my Ender 3 Pro now dead atm, with which I do all my tests I decided to update my Anet A8. Since I can't compare the degree I can say the stuttering is still evident. |
|
Using the latest commit (1475fd3) with |
|
By disabling |
Bro if you are in the USA I have a spare stock motherboard I can send to you to get you back up. I used bugfix for a day and a half before I realized JD was ruining my prints. |
|
@cwizard Thanks for the offer! I'm in Germany and will try to get a replacement. |
|
Hi, where I can comment on the function JD_USE_LOOKUP_TABLE? I have CONFIGURATION_H_VERSION 020005 and I have the same problem with motion stutter. |
|
@davevo22 |
|
I searched there but did not find it. Row number? |
|
Around line 43 |
|
Here are the results using Cura_SteamEngine 15.01 (Repetier-Host) in standard mode with the same settings as before.: |
|
The Cura sliced files looks quite a bit different concerning segment lengths. Histogram detail: Curvature / Equiv. radius: Note that the max Y value is a bit higher than in the earlier plots. This GCode has much fewer segments below 0.5 mm. Segment length distribution isn't super consistent, but differences between consecutive segments are less pronounced than in the GCode sliced by ideaMaker. This is also evident from the sharper/thinner distribution in the histogram. A typical layer looks like this: I'm still searching for a metric which is somewhat correlated with those bulges. I expected the width of the distribution of equivalent radii to be a candidate, but it doesn't look like it is 🤔 |
|
@Lord-Quake Could you run the standard print sliced by ideaMaker again, but this time, comment out |
|
Both instances? Lines 2505 and 2389 |
|
There should be only a single instance of this exact line in the latest bugfix-2.0.x. This one: Marlin/Marlin/src/module/planner.cpp Line 2389 in 2d1cbf8 |
|
Yes, you correct.... will do the test now. |
|
Well, this took a lot longer than I had wanted because my nozzle crashed in to the bed due to a little piece of filament stuck to the nozzle while leveling..... In my opinion this is how Marlin should look like :-) I will be doing more tests, not that this a fluke but I expect the other tests will show the same results. |
|
Even if it's a stupid question, but why do we need these limits: vmax_junction_sqr and limit_sqr? |
Yeah, I agree. Also, that 100% confirms what I was suspecting:
As I said before, I also think that those excessively low junction speeds come from the fact, that the estimated radius is too low - most likely because some segments are aligned incorrectly by the slicer. Thank you very much for testing this again! 🍻 |
The normal JD code determines junction speeds only based on junction angles. That means, if you slice an identical curve with a different number of elements, the one with more elements would print faster (because each junction angle is smaller, when there's more elements). |
|
I did some more tests. Firstly I designed a new test object for quicker prints. I call it "Boomerang" :-) Here the file if anyone wants to test: Boomerang.zip One test was with 1 wall (0.4mm) and the other with 2 walls (2x0.4mm). Parts in full view: Looking good right? Well, yes..... However, I think I've found a "new" issue that probably is completely unrelated to our issue. |
That line from 10 o'clock to 16 o'clock on the brim? 😀 |
|
(buzzer) Incorrect ;-) |
|
Closeup (for the blind) Haha....
|
|
Blob on topmost layer? |
|
(buzzer) We have a winner 👍 Seriously though.... On every print the nozzle halts for a split second on the last layer just before the print finishes. This is new.... |
|
Weird. Maybe check your buffer size or turn off Back to the main topic: How do we proceed with our |
|
If that blob is about plannerbuffersize segments before the part is ready - try a M400 after the last moving g-code of the part. Could be EEPROM activity, closing files, updating printcounter, ... , things done when finishing a print. M400 will delay that until the part is finally printed - not only finally planed. |
|
@AnHardt M400 didn't help. This issue is new and I'll look into it deeper with a separate open issue entry if needed. |
|
From my point of view, we have definitely identified that Let's look at some random curve, which we slice into segments of different length. Our hypothetical slicer works well, but it's got some quirks. Now let's look at three of those sliced segments and their junction angles: Slicing variant A
On slicing variant A you can see, that our hypothetical slicer decided to insert a small segment This is incorrect - the curvature should be distributed evenly amongst both junctions. But it is also not problematic for Marlin. The junction speed for segment Marlin/Marlin/src/module/planner.cpp Line 2435 in 75119c4 For segment 3, the junction speed will be a little bit lower than it should be for a perfectly sliced curve, but because the segment is much longer than 2, the junction speed will still be high enough to not be limiting in most real world scenarios. It is technically too low, but it will most of the time still come out at something like 60 mm/s, which happens to be enough to cause no problems during printing.
Slicing variant B
On slicing variant B you can see that our slicer again inserted a small segment, but this time, the junction angles are distributed in reverse: The angle on This is just as incorrect as slicing variant A. But this time, it also creates a big problem in Marlin: The junction speed for segment I am very, very certain that this is our main problem with Maybe it's the slicer's fault, maybe this comes from the polygon boundaries in the STL, I'm not sure. But I currently see no clean solution. What are your ideas? |
|
In each scenario you're looking at the eventual curvature / change in angle starting from point 1 and going out to point 3. In a longer scenario you could go out to point N. The total change in angle would seem to be the relevant issue. What is interesting is that whenever you change angle in a set of 2 or more moves, the line directly from point 1 to your destination will "always" be shorter than the total of all the segment lengths. (That assumes a continuous curve and not a zigzag.) Of course, it's just the hypotenuse…. The shorter it is in relation to the total move length, the more acute the curvature. So, anyway, given that we keep describing change in angle over multiple segments, it seems like we should be running some algorithm here that looks ahead from the start of the planner to the end of the planner, building on the current momentum, and which can account for all the angular change ahead, attenuating all the way back to the first planner segment. |
|
…which is in a sense all that "jerk" does. It looks only at the amount of speed change being proposed on each axis by the "nominal speed" move that has been appended to the current buffer. Jerk limits are applied only on junctions where direction changes occur on one or more axes. The rest of the speed attenuation is handled in terms of acceleration and max feedrates per axis. Higher jerk values used to be the trick to get sharp corners. So, it seems like what might work best is some combination of approaches. If there are weird edge cases that can mess with JD, clearly the long term solution is to have JD look for those cases and manage them by doing some form of averaging. Perhaps there is some way to see these sudden jumps / drops in speed as they are about to occur and then apply extra logic to solve the dilemma…. |
|
I'm just a lurker so yell at me if I'm out of order, but I don't see a possible solution to this without reading ahead in the planner (or forcing gcode to use arc segments which obviously isn't a valid solution). So the first question (since I suck at reading C/C++) is how far ahead can we read? And is that a guaranteed amount (blocks I assume) or subject to variation based on other factors? |
|
@campiosa — We've had a good discussion on approaches to lookahead or "deviation accumulation" in another thread but I can't find the issue number at the moment…. |
|
Duplicate of #17342 |
Bug Description
Curved extrusions stutter (multiple full stops in the middle of a continuous curve) with Junction Deviation enabled. Enabling/Disabling S Curve and Linear Advance (indepentently and in combination) does not remedy the problem. Adjustments to acceleration and junction deviation value do not remedy the problem.
Disabling Junction Deviation remedies the problem, even with S Curve and Linear Advance both set.
My Configurations
Required: Please include a ZIP file containing your
Configuration.handConfiguration_adv.hfiles.Working_configs.zip
Stutter_configs.zip
Expected behavior: Smooth curve motion, as expected based on baseline experience.
Actual behavior: Stutter/halting during curve motion.
Additional Information
Configs and example video attached.
The text was updated successfully, but these errors were encountered: