[3.6 / 4.0 Beta] Spiralize Outer Contour generates unnecessary G0 moves between 'layers'.

[JohnEdwa]

This is a bug I noticed using the Klipper firmware, that issue can be found here.

---

Using Spiralize Outer Contours sometimes results in the small move being generated between layers, which makes Cura use G0 and the Travel speed and acceleration for it:

G1 X93.356 Y111.876 Z0.799 E89.3227
G1 X93.785 Y111.421 E89.34388
G1 X94.145 Y111.06 E89.36115
G1 X94.51 Y110.713 E89.37821
;TIME_ELAPSED:66.517663
;LAYER:5
M204 S1500
;MESH:Woman_body_for_vase_mode_v13.stl
G0 F13500 X94.51 Y110.713 Z0.8
M204 S1000
;TYPE:WALL-OUTER
G1 F2100 X95.171 Y110.125 E89.40818
G1 X95.595 Y109.772 E89.42687
G1 X96.086 Y109.383 Z0.801 E89.44809

That move has the exact same X and Y coordinates as the last one, and the movement in Z-axis is a whopping 0.001mm.

The issue is that these somehow freak up the Klipper firmware and it takes just a fraction of a second longer do this move, and also thinks it's large enough change in speed to do a pressure advance retract which results in a very visible seam on the print. While this could be a bug in Klipper itself, the issue is fixed if these G0 commands are simply commented out from the G-code and as they look like they really shouldn't be there in the first place, fixing them in Cura would make sense as well.

Application Version 3.6 and 4.0 Beta. Both create these.

Platform Win 7 64-bit

Printer Ender 3.

Additional Information Project File and 3.6 sliced G-code: CE3_Woman_body_for_vase_mode_v13.zip

[smartavionics]

Hello @JohnEdwa , thanks for the report, I will look into it tomorrow and see if the travel move can be omitted. BTW, why keep switching the acceleration? Does it really help in any way?

[JohnEdwa]

@smartavionics I've just set "Print Acceleration" to 1500 but kept the walls at 1000 as that's what it was in the Marlin config by default. I mostly use it to give Cura better print time estimates.

[smartavionics]

A possible problem with frigging with the acceleration (and jerking with the jerk!) is that it can interfere with the firmware's motion planning. Personally, I avoid altering them unless it's absolutely necessary. Anyway, I will investigate this issue.

[JohnEdwa]

Here's some info as to why Klipper freaks out on this:

Almost assuredly this results because Klipper does not do lookahead across moves that have significantly different extrude rates. The Z only move doesn't extrude while the previous and following moves do. Klipper interprets this as a request to make a move without any extrusion and thus decelerates so that the extruder can come to a full stop (and so Klipper can perform any pressure advance if so configured). FWIW, this behaviour is documented in docs/Kinematics.md .

I'm not really sure how one could avoid the deceleration in the general case. So, I don't immediately see a way to avoid the issue you are seeing. (Other than fixing Cura, of course.)

-Kevin

Which makes sense, Cura is telling it to stop extruding, move up and then continue extruding, which it obviously can't do in the time it takes to move 0.001mm at 225mm/s, and it slows down drastically.

[Ghostkeeper]

Waiting for extrusion to stop completely is not a smart idea. Didn't Klipper have this "junction deviation" parameter that specified it was allowed to get like 0.15mm off the desired path?

Anyway, I would bet my lunch on this being a rounding error in the Z position interpolation in spiralise mode.

[smartavionics]

Anyway, I would bet my lunch on this being a rounding error in the Z position interpolation in spiralise mode.

That's my guess too, will be looking at it later.

[smartavionics]

Hmm, I can't recreate the problem here at the moment. Which Cura release did you use to create your gcode file above? Was it an UItimaker release or one of mine?

I have some changes in mind but if I make changes I need to be able to verify that they actually cure the problem which is diffilcult right now as I can't recreate the problem. Will continue to look into this....

[JohnEdwa]

Right, I didn't realize there could be two separate things that have the same result on the printer. This specific one was done just by by master 20181210 (last Cure 3 UI one) and is most likely fixed already, as the one that does it in 4 Beta (and is in 3.6, 20181210 and 20190127 master as well) is instead the one making:

;MESH:NONMESH
G0 F13500 X122.225 Y127.759

...at the end of some layers. These trip up Klipper as well for the same reason and have the same result, a move without extrusion stopping the head, but have nothing to do with spiralize code as far as I can see. Sorry for sending you on a wild-goose chase with this one.

[EDIT] Would it be possible to add the master build date to the .gcode ;Generated with Cura_SteamEngine master to protect from idiots like me?

[smartavionics]

I still think that you have highlighted a possible problem with the spiralize code that is worthy of attention. I shall add some rounding which should avoid any problems in the future.

[JorgeUliana]

Hello friends, I found this same bug doing a simple empty cube, but without being in spiralize mode. Actually with the spiralize mode the problem has been solved.

;MESH:Object 1 G0 F7200 X134.8 Y134.801 Z0.3 M204 S500 M205 X20 Y20 ;TYPE:WALL-OUTER G1 F2400 E0 G1 F1416.2 X85.2 Y134.801 E2.47455 G1 X85.2 Y85.199 E4.94921 G1 X134.8 Y85.199 E7.42376 G1 X134.8 Y134.801 E9.89842 M204 S5000 M205 X30 Y30 G0 F7200 X134.6 Y134.801 G0 X134.4 Y134.401 ;MESH:NONMESH G0 X134.8 Y134.801

Cubo OCO 50x50 Cura.zip

[JorgeUliana]

[smartavionics]

OK, that's a different issue. What I think it is doing there is that at the end of the lines output by each extruder it puts in a travel to move the nozzle away from the wall. The idea is that it is trying to avoid retracting on the wall. Unfortunately, it does this even when there isn't going to be a retraction because the end coordinates of one layer match the start coordinates of the next layer. But it does the useless move anyway. That's a bug or a feature depending on how generous you are feeling.

[JorgeUliana]

Actually at first I understood that it could even be purposeful, but when I found this post, I believed it was not.

I'm doing a comparison between slicers, because I believe that the Cura is the best, but I would like to prove and realized that the amount of G codes generated by the Cura is always much bigger than the others and so I ended up finding these movements in G0.

[JohnEdwa]

@smartavionics

That's a bug or a feature depending on how generous you are feeling.

I guess you could say it is a wipe of some sort, but they definitely shouldn't be done when Spiralize is enabled. Especially when they seem to pop up rather randomly as the model has 1466 layers and only 337 of these nonmesh moves.

[smartavionics]

That little jiggle is not done when spiralize is enabled. My response above was slightly wrong, the move away from the wall occurs at the end of each part (region surrounded by air).

[JohnEdwa]

Hmmh, so what's creating them in the Spiralize gcode then? If I use 4 Beta to slice the bust with "Spiralize Outer Countour" enabled, there are 980 layers in total, 118 instances of ;MESH:NONMESH followed by a G0 found at the end of some layers:

G1 X97.419 Y119.546 Z3.44 E164.36898
;MESH:NONMESH
G0 F13500 X97.418 Y119.545
;TIME_ELAPSED:136.426490
;LAYER:27
;TYPE:WALL-OUTER
;MESH:Woman_body_for_vase_mode_v13.stl
G1 F2100 X97.602 Y118.922 E164.39098

and a total of 134 counts of G0movements, none of them with an extrude so Klipper will pause at them creating a blip. CE3_Woman_body_for_vase_mode_v13_4_beta.zip

[smartavionics]

Hi John. Those tiny travels are being inserted to move from the end of the last line on one layer to the start of the first line on the next layer. As you can see they are very short (a couple of microns). It's a shame that klipper can't hack them. My development version of Cura doesn't produce those particular short travel moves. I made some changes to the spiralization many moons ago and maybe something I did back then stopped those short travels being created. To be honest, I can't remember. The changes I made have been available for incorporation into Ultimaker's release for a long time but they obviously have other things on their minds as they are not processing any of my (or anyone elses) contributions. So, if you want blemish free spiralized prints, I recommend you install one of my releases which can be found at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0.

[JohnEdwa]

I've been using your build for months now actually, that's why my original report was done on the 20181210 master build, and they are there still. I tested on the 20190130 build as follows:

• uninstall Cura Master
• remove C:\Users\JohnEdwa\AppData\Roaming\cura\ and C:\Users\JohnEdwa\AppData\Local\cura
• install 20190130 Master build.
• open the project file in the first post, slice.
• open G-code in notepad++ and count 225 instances of "NONMESH" and 231 instances of "G0":

G1 X94.673 Y109.86 E247.32417
M204 S1500
;MESH:NONMESH
G0 F13500 X94.672 Y109.859
;TIME_ELAPSED:200.253818
;LAYER:27
M204 S1000
;TYPE:WALL-OUTER
;MESH:Object 1
G1 F2100 X94.982 Y109.614 E247.33756

CE3_Woman_body_for_vase_mode_v13_20190130.zip

[smartavionics]

That's interesting as I don't get those small travels. Maybe it's a difference due to the fact that I am using Linux and you are using Windows? I will continue to investigate.

[smartavionics]

Hi @JohnEdwa. Yes, those small travels occur when your model is sliced on Windows but not on Linux. I have made a change to the spiralization code and a new exe is being uploaded to dropbox. Please try it and see if the travels have gone away.

[smartavionics]

The fix has been added to https://github.com/Ultimaker/CuraEngine/pull/925.

[JohnEdwa]

@smartavionics I can confirm that they are gone :+1:

[smartavionics]

And they really should fix klipper so that it doesn't care about those little moves. It's not uncommon for slicer's to have rounding issues so it would be better if the firmware was robust enough to cope with a little imprecision!

[JohnEdwa]

The problematic part is that there is no extrusion during that move which makes Klipper slow down so it can stop the extruder and do a pressure advance retraction, which in theory is exactly what it should do as Cura has told it not to extrude during that move.

In practice it really shouldn't do it for such a tiny thing, but the current motion planning stops immediately when it sees it coming. Marlin glosses over them completely because its Jerk setting also works for the Extruder and it's really, really hard to get an extruder to Jerk at any magnitude:

10 mm/s on E -- that is ~24mm3 of filament (1.75), that is 300 mm/s X axis speed with 0.4 width and 0.2 layer! If constant X speed in first part was below 300mm/s -- X axis will not need to accelerate/decelerate at all.

Well, we see what Klipper issue 1172 results into.

[smartavionics]

Understood. Well, in an ideal world the slicer should be able to cope with small errors in models and the firmware should be able to cope with small errors in the gcode. None of the SW is perfect but, hopefully, the wrinkles get removed as they are discovered.

Sorry, I didn't twig what was going on here earlier. It didn't occur to me that a Windows Cura would produce different numbers to a Linux Cura. Interesting as CuraEngine is compiled using gcc on both platforms and the calculation that was causing the rounding error was just a simple expression with no trig or other math functions used. A lesson learnt.

[JohnEdwa]

Well, I though I had just wasted your time doing a slice on an old, custom version complaining about bugs that you had were already fixed. Mistakes happen, but this time they ended up with finding and fixing another bigger problem, so we'll call it even ;P

Still, see if you could swap the version from "Master" to show the build date instead, would be useful.