CuraEngine
CuraEngine copied to clipboard
Ultimaker
Arachne regression: stutter printing circles
The attached test piece prints smoothly with CuraEngine 4.x, but with stuttering motion (and corresponding problems with extrustion/surface quality) using Arachne. I'm running Klipper firmware with SCV=10 and acceleration 2000, speed 150 but I would expect the same with modern Marlin using junction devition; I'm not sure about legacy Marlin with the old jerk. I have not analyzed the gcode output in detail but I suspect Arachne ends up alternating slight line width variation between the outer and inner wall, producing a zig-zag motion rather than a smooth turn of 4 degrees on each segment corner, thereby interfering with the acceleration profile.
I can provide profile information if needed, but I don't think it is; I played around with the beading settings etc. a good bit and the problem did not seem to diminish or change at all.
(Note: I edited this because I accidentally uploaded the wrong version of the file the first time.)
It is indeed adjusting the speed to keep the flow constant. If you set Flow Equalization Ratio (speed_equalize_flow_width_factor) to 0, does that improve the result?
I'm also seeing a possible bug here with one extra vertex being introduced, causing a 0.009mm move. The move occurs on the left side (towards negative X) of the model and is exactly towards negative Y so it shouldn't be a sharp corner, but it is wrong. I don't think it's the issue you're seeing though, unless you're seeing the stutter only on the same place on the left side every loop.
I don't think it's flow equalization - that's off by default as far as I can tell. The behavior sounds a lot more like the 0.009 mm move, where the junction angle is entirely quantization noise. Perhaps I'm getting more of those than you are for some reason (like resolution/deviation settings). I'll see if I can narrow it down from that.
The (at least partial) culprit seems to be Maximum Extrusion Area Deviation, which I had dropped to 0 trying to solve the warts issue. Increasing it back to 2000 gets mostly smooth motion, but I wonder if that could cause significant over- or under-extrusion. 2000 µm² is 0.044 mm by 0.044 mm as a square, which is small but not tiny in the scale at which extrusion accuracy matters.
FWIW the increased precision work @Piezoid is doing, if it's acceptable upstream at some point, would probably make it so these quantization-error problems don't come up in the future.
That would make sense. The Maximum Extrusion Area Deviation determines how much it's going to split up a line with variable line width. So if a line should be wider on one side than the other, setting it to 0 results in theoretically an infinite amount of lines. (In practice, infinitely less than infinite.)
The cup has a variable line width in the corners. While the vertices are properly aligned between the inside curve and the outside curve, the distance from the inner vertex to the outer vertex (in a corner) is still larger than the distance from the inner edge to the outer edge (in a straight bit). The transition from a straight bit to a corner has variable width. This can lead to very high resolution g-code if the line width is strongly constrained to deviate 0µm² from the ideal line width.
Perhaps it would make sense to do something to allow deviation only in one direction (less than ideal extrusion area) rather than either direction so that it can't interfere with dimensional accuracy of the outer walls (via overextrusion forcing them outward).
All of the extrusion area deviation is in both directions equally.
Let's say you wish to print a line with a length of - say - 10mm that changes from 0.4mm width to 0.2mm width. This line has a variable width, and its area is a trapezoid shape. If the maximum resolution is 10mm and the maximum deviation is infinite (no maximum) then it would try printing that with 1 line, 10mm long and a width of 0.3mm.
However this rectangular line deviates from the idealised trapezoidal line. There are four triangular areas of deviation: Two on the fat end of the line where the printed line is too thin (0.3mm instead of 0.4mm) and two on the thin end of the line where the printed line is too fat (0.3mm instead of 0.2mm). The total area of the printed line is correct, but where it places that material is not. In this example, the deviation is (5mm*0.1mm/2)*4 = 1mm²
With a limit to the deviation, it forces breaking that line into pieces. For example, if the maximum area deviation would be 0.5mm², you'd get two line pieces. One for the first half of the line printed at 0.35mm width (the average between 0.4mm and the 0.3mm halfway point) and one for the second half printed at 0.25mm width (average between 0.3mm and 0.2mm). Each of these line segments has a deviation of (2.5mm*0.05mm/2)*4 = 0.25mm², and so is within the specified deviation limits.
Breaking up the lines in favour of overextrusion or underextrusion doesn't really make sense, since each segment in total doesn't overextrude or underextrude. It's all just a matter of how long a line gets averaged out.
Thanks for explaining it in more detail. I was under the impression that this option gave it the freedom to over- or under-extrude by some degree to avoid having too many tiny segments, but indeed what you say makes sense, and as long as outer walls are printed first or at least the innermost wall with width deviations is printed last, the existing walls should constrain the flow of extruded material to make it end up exactly where it's supposed to.
On a somewhat related issue, I've found that turning the transition threshold way down from the default 50% seems to help with some of the outer wall dimensional accuracy issues I was hitting. A value comparable to what I used for "Minimum Wall Flow" pre-Arachne (10%) seems to work well for me. I'll follow up on the issue this actually belongs on.
Actually, we found values of 80%-90% to be printing best.
It's not really up to me to optimise the printing profiles. Ultimaker has a group of process engineers that do that.
It's possible that the only reason low values help me is by compensating for https://github.com/Ultimaker/CuraEngine/issues/1495 (not that exact case, but ones where merging inner walls from both sides makes the same issue manifest). However, I print at speeds where increasing the flow further might not even be possible, and even if it is, it's pushing the limits of the pressure advance spring model to the point that extrusion may be inaccurate, so more narrow lines are preferable. It's possible "Equalize Filament Flow" with the appropriate settings might change that; I'll experiment once the fix for the referenced bug is merged.
BTW is there or will there be documentation for how the transition threshold settings work now? I found the descriptions in the json really hard to understand.
I'm planning to update the Settings Guide soonish. That guide has the visual space to actually thoroughly explain it. Should start with that earlier than usual because this update changes a lot. Of course this is what I do myself outside of Ultimaker's employ.
Within Cura itself we don't have a lot of room to write an extensive description, but suggestions are welcomed. Direct wording, or just if you feel like a certain fact should be included in the description. I don't think we can explain exactly how it's calculating the number of lines though. Formulas should be avoided in general.
This can probably be closed as just a configuration problem, but I would like to point out that @Piezoid has a working branch https://github.com/Piezoid/CuraEngine/commits/improve-precision that fixes pretty much all the issues of stuttering from numerical precision issues. My understanding is that some of these commits are just getting things making consistent use of the existing system for converting between floating point mm and integer units (rather than hard-coding the scale) and would be appropriate to go ahead and take upstream even if the increased precision changes are not (yet) desired upstream.
This can probably be closed as just a configuration problem, but I would like to point out that @Piezoid has a working branch https://github.com/Piezoid/CuraEngine/commits/improve-precision that fixes pretty much all the issues of stuttering from numerical precision issues. My understanding is that some of these commits are just getting things making consistent use of the existing system for converting between floating point mm and integer units (rather than hard-coding the scale) and would be appropriate to go ahead and take upstream even if the increased precision changes are not (yet) desired upstream.
This branch allow changing the integral unit size from 1 µm, to 0.1 µm, or even 1 nm. I wanted this to smooth the motion on small detail by being able to reduce the meshfix_maximum_deviation below 30~40 µm, without risking near-self intersections that make then engine segfault on the trapezoidization output.
It does indeed reduce the quantization noise, but there is others changes (705b0e2b), notably lowering discretization_step_size to 100µm (currently 800 µm). This hard-coded value, as I understand it, sets the minimum move length when discretizing varying width extrusions into segments of constant section.
I don't know which change the more helping the most with this specific issue, but shirking the step size should smooth the motion of both the toolhead and extruder during transitions to a different number of lines.
Perhaps discretization_step_size could be made dependent on the meshfix_* settings?
Lowering the discretization_step_size has its own dangers though, the larger the amount of commands becomes (and we'd need more commands since we're changing the flow more often), the larger the chance of introducing stuttering (or other problems caused by micro-segments) as well, at least on certain printers.
A hardcoded value is indeed not pretty, but I think we're drifting further from the original intent of this issue then.
I indeed think we can close this now.
