Uneven flow rate and machine stuttering using Arachne beta with simple model

daniels220 commented 2 years ago

Application Version

Arachne engine beta 2

Platform

macOS Big Sur

Printer

Creality CR-10s

Reproduction steps

I discovered this with the same model as in #11150—a simple tapered, hollow cylinder with a wall thickness of exactly two lines. Aside from the issues with the brim and Z seam, I noticed the printer stuttering in the middle of the print—briefly slowing down and speeding back up rather than sweeping smoothly around the circle.

I figured I'd have a look at the gcode to see if anything obvious jumped out, and found that the output from the Arachne engine beta is a full 1.2MB larger than that from Cura 4.12. Certainly part of this is from the travel moves mentioned in #11150, but...aha! Looking at the code, I see that Arachne is causing the feed rate to constantly vary extremely slightly—almost certainly far too slightly for the stepper drivers to actually reproduce—which may be contributing to the problem:

;LAYER:1
M106 S85
;TYPE:WALL-OUTER
;MESH:178vac.3mf
G1 F1350 X166.238 Y166.272 E39.1923
G1 X165.996 Y166.517 E39.20661
G1 X165.138 Y167.301 E39.25493
G1 **F1352.7** X164.858 Y167.549 E39.27045
G1 X163.973 Y168.253 E39.31737
G1 X163.651 Y168.502 E39.33426
G1 X162.752 Y169.126 E39.37967
G1 X162.387 Y169.371 E39.39791
G1 **F1350** X161.476 Y169.918 E39.44209
G1 **F1352.7** X161.065 Y170.156 E39.46179
G1 X160.146 Y170.625 E39.5046
G1 **F1350** X159.692 Y170.849 E39.52565
G1 X158.775 Y171.245 E39.56718
G1 **F1352.7** X158.277 Y171.451 E39.58954
G1 **F1350** X157.367 Y171.774 E39.62969
...etc...

(Emphasis mine.) The Cura 4.12 output is similar (though the coordinates are different because the Z seam is in a different location), but the feed rate doesn't change once it is initially set.

But clearly that's not the whole of the issue, because the variance I was actually experiencing was far greater than that, more on the order of if it were dropping to F500 or something. It's possible that my printer is unable to keep up with the gcode, though with such a simple model and stock resolution settings I find that unlikely. More likely is a bad interaction with the linear advance or junction deviation algorithms in Marlin, but given that this doesn't happen with 4.12 Cura is clearly contributing.

Also, turning flow rate compensation down to 0 gets rid of the feedrate jitter but the output is still 0.9MB larger. (I haven't actually tested to see if this gets rid of the stuttering—if that would be helpful I can do so.) I can't so easily tell whether this is a result of higher-precision moves (dividing the circle into more segments), or if something else is going on, but doubling the "maximum resolution" (which, confusingly, reduces "resolution" as most people think of it, the help makes it very clear that it's the "minimum length of a segment after slicing", so longer is rougher) setting only makes the file 100kB smaller, still much bigger than 4.12's output.

There might be a clue here in the "flow" mode of preview display—Cura 4.12 is perfectly even, while Arachne is all patchy and weird, even with flow rate compensation turned all the way up:

Cura 4.12:

Arachne beta:

Doing some more investigation revealed another problem. I was able to confirm that flow rate compensation is doing something, just not perfectly, as the situation with it turned off looks much worse:

In any case, I am not convinced that either one accurately reflects the real-world behavior of the printer. I haven't gone through and compared the extrusion distance divided by travel distance manually, and there's rounding to be considered, etc, so maybe Arachne is generating different, erroneous, gcode compared to Cura 4.12. It seems equally likely, though, that it is just being too picky But then I stumbled across a new problem, when this happened:

I wonder if Cura is accidentally including travel moves in flow-rate calculation somehow? I find it extremely suspicious that the layers with anomalously long travel moves also have anomalously high calculated flow. In any case, this is non-deterministic—it happens about half the time, maybe a little less, when re-slicing after changing settings, including those unrelated to speed or flow rate. The position of the anomalous layers is also random.

Actual results

Weird variations in flow rate and strange behavior by the actual printer.

Expected results

Same as Cura 4.12, smooth motion and no calculated flow rate variation.

Checklist of files to include

[ ] Log file
[X] Project file

Additional information & file uploads

Copied from #11150:

Raw model: TaperedHollowCylinder.3mf.zip

Project as saved by Cura 4.12: Cura412Project.3mf.zip

Project as saved by the Arachne beta: ArachneProject.3mf.zip

fvrmr commented 2 years ago

Hi @daniels220 thank you for making a separate issue for this bug. I will bring this also up for discussion, keep you posted.

fvrmr commented 2 years ago

I have discussed this with the team and it turns out that the flow rate in Arachne is correct, however it is maybe not be desired behaviour. This is because of all the segments in your model. Did you use the same project file for Arachne and 4.12? And does it stutter on ever segment or only on maybe the place where the seam is?

daniels220 commented 2 years ago

This is because of all the segments in your model.

I mean...yes? But, all models have these segments, because we're slicing from a mesh, not e.g. directly from the parametric curvature of the source model (assuming the source model is parametric), yet Cura 4.12 doesn't get tripped up by it. I'm not sure what you're saying here?

In any case—I used the same raw source model in Cura 4.12 and Arachne, with completely stock settings (freshly reset ~/Library/Application Support/cura) for each. I didn't strictly speaking use the same project file, but the model mesh is identical certainly. And no, the stuttering happens in randomly-distributed locations around the circumference, not associated with the Z seam.

Ghostkeeper commented 2 years ago

I think what fvrmr meant is just buffer underrun, a conclusion you also considered:

It's possible that my printer is unable to keep up with the gcode, though with such a simple model and stock resolution settings I find that unlikely.

It seems that with flow rate compensation set to 100%, it's arriving at a mix of flow rates of 2.4950202mm³/s and 2.5mm³/s. I'm not sure where the remaining 0.005mm³/s is coming from, but it is within the realm of rounding errors. For instance, with line segments of 0.25mm like in your print, this flow difference can be caused by having the line be 501nm longer. Since Cura rounds coordinates to micrometres, 0.5um differences are to be expected. It just gets amplified by the colour scheme since all the flow rates in the print are similar. You could amplify it further by setting the initial layer speed to 25mm/s.

So bar rounding to microns, the flow rate compensation seems accurate to me.

Your story is a collection of possible issues. We can't really help with buffer underrun if that is the case. We can only help with the g-code output if it is wrong. The g-code being bigger is not necessarily an issue if it spreads out the high-resolution areas better. Arachne is expected to spread it out better since the Wall Overlap Compensation from 4.13 and before adjusted the line width only on one side of the overlap rather than on both. Of course, the Maximum Deviation and Maximum Resolution should still hold.

I'm unable to reproduce your issue with the straight line overhanging so far. I've sliced your Arachne project file a dozen times. Maybe it's already fixed since the beta. Or maybe it's only on MacOS? In any case, it would be good to track separate issues separately.

GregValiant commented 1 week ago

Is this still a problem with the current stable version of 5.8.1? Can this be closed?

Ultimaker / Cura