UltiMaker Cura 5.6 creating unecessary moves

[Luxor144 0]

Trying to print a part that I sliced with UltiMaker Cura 5.6 and controlling my printer with OctoPrint. I've noticed that printhead is doing some random jittery movement during the infill phase. Second picture is the movement code for the infill. As you can see, there's a bunch of short green lines (movement without extrusion) that don't really make sense. I've also noticed that sometimes it would start going in a straight line, stop for no reason and go do another line instead (which again, doesn't make any sense as it would be more efficient to just complete line after line instead of jumping between them). This usually wouldn't be that much of a problem, as it's just a small waste of time, but given that there usually is a bit of oozing, these unnecessary movements degrade the print quality.

Any idea what causes this or which settings could be altered to alleviate this issue?

grippy.gcode

Edited February 4 by Luxor144

[Slashee_the_Cow 271]

If you could point out a specific layer, that would help. But going move by move through a couple of layers it looks completely normal to me: it prints support first (all the support, regardless of how far apart it is, before it gets to anything else) then you have it set to do infill before walls, so it goes to the infill, sometimes it's drawing very long straight lines (good thing!) but that means it can be a bit of a distance away from any other infill lines it needs to print (and you have it on cubic subdivision by the looks of it? Requires a lot of short moves to draw lines around the long lines it's done) so it may have to travel some distance back to the next to part it needs to do.

 

You could try going to Experimental > Infill Travel Optimisation and turning that on to avoid long infill moves in travel (you may have to make all settings visible). But as a whole, it looks completely normal.

 

If you want some more help, if you could provide the Cura project file (.3mf, in Cura get it ready to print then go to File > Save Project) that would help a lot more than the gcode.

[ahoeben 1,951]

5 hours ago, Slashee_the_Cow said:

you may have to make all settings visible

Or simply use the search.

[GregValiant 1,258]

At the end of the very first infill line (gcode line 5257), there is this little dance...

G1 F4500 X113.839 Y105.925 E653.28732 >>> long extrusion

G1 X113.799 Y105.855 E653.28866
G1 X113.839 Y105.925 E653.29
G1 X113.799 Y105.855 E653.29135
G1 X113.839 Y105.925 E653.29269
G1 X113.799 Y105.855 E653.29403

It's shuffling back and forth between two points and extruding every time.  That really doesn't look right.  It almost looks like it gets stuck in "Infill Wipe" before moving on.

 

The same sort of thing happens at line 5318.  It's a stutter-step.

G1 F4500 X86.16 Y84.516 E658.30881
G1 X113.84 Y84.516 E658.76913
G1 X111.802 Y84.516 E658.80302
G1 X111.803 Y84.516
G1 X113.84 Y84.516 E658.8369
G1 X111.803 Y84.516 E658.87077
G1 X113.84 Y84.516 E658.90465
G1 X113.751 Y84.516 E658.90613

 

Some of the movements are very short.  Almost as if it's a Maximum Resolution thing.  Since it occurs in the infill, I don't know if that applies.

 

 

Edited February 4 by GregValiant

[Slashee_the_Cow 271]

45 minutes ago, GregValiant said:

Some of the movements are very short.  Almost as if it's a Maximum Resolution thing.  Since it occurs in the infill, I don't know if that applies.

Sure it isn't just the infill pattern? Cubic (and cubic subdivision, which is what I think this is by looking at it) draws as many lines as it can as long as possible, but that results in a bunch of small sections that need filling and gaps between intersections. Just look at all these little travels:

Disclaimer: Any resemblance to parts of human anatomy is due to its placement on the build plate, using a top down view with the origin in the bottom left, as is default for that view, and/or your dirty mind.

[GregValiant 1,258]

I refuse to rise to the bait.

 

Those moves are on the order of 0.08mm.  There are longer ones as seen in the preview, but those short ones stick out like a sore thumb (sort of like your image there).

 

[Luxor144 0]

Well, I didn't have the original Cura project saved, so I thought hey, I'll just remake it, since I couldn't avoid that problem before. So, naturally, I can't get the same bug to trigger now. Cura 5.60 slices everything fine, no random unnecessary moves. And since there's no random dancing during infill, both print time and file size is cut down in half.

 

No clue what the problem was, but it was a fresh update, so maybe so interference between versions that disappeared after restart (doesn't sound very plausible, but stupider things have happened). However, I've noticed that I still have 5.40 version. I've tried to slice the model on it, and lo and behold - the jiggly is back.

 

So yeah, I guess my problem is solved by using 5.60 instead of 5.40 (even though it was 5.60 version doing the dance yesterday, but whatever). I'm still uploading .3mf file because it would be good to know what exactly could have triggered this issue (some messed up setting somewhere, weird bug caused by orientation, etc.)

Grip project.3mf IndexGrip.stl

[GregValiant 1,258]

This is from the gcode when I sliced that project.

G1 X93.334 Y126.75 E655.01482
G1 X90.175 Y121.266 E655.12007
G1 X88.205 Y121.266 E655.15283
G1 X111.795 Y121.266 E655.54513
G1 X111.783 Y121.266 E655.54533
G1 X111.795 Y121.266 E655.54553
G1 X107.85 Y121.266 E655.61114

My guess (and it's only a guess) is that it's related to "Gradual Infill Steps" when the infill is "Cubic Subdivision".  I changed to a couple of other infill patterns and the problem went away.  In addition, "Gradual Infill Steps" doesn't seem to be implemented correctly with Cubic Subdivision.  It starts out at the "Infill Density" and then seems like it goes over it again with the "Step density".

[Slashee_the_Cow 271]

8 hours ago, GregValiant said:

In addition, "Gradual Infill Steps" doesn't seem to be implemented correctly with Cubic Subdivision.  It starts out at the "Infill Density" and then seems like it goes over it again with the "Step density".

Gradual Infill Steps doesn't (shouldn't) apply with a Cubic Subdivision pattern. The infill step options are disabled and aren't even visible. Infill steps make it use less infill at lower layers then slowly graduate up to full density at the top to save time and filament. Cubic Subdivision already does a similar thing by filling any large voids in the model with big, empty cubes where high density isn't required for strength.

 

If I may zoom in on certain parts of my purely scientific screenshot:

Just look at all these tiny moves. I'm guessing a bed slinger might vibrate a bit doing that, so you may want to watch your jerk value.

 

Disclaimer: All terminology used in this post is the correct terminology for that context. The author expects this content to be taken at face value and is not responsible for any potential misinterpretation.

Edited February 5 by Slashee_the_Cow

[GregValiant 1,258]

This is from the end of the gcode file that the OP posted:

\\ngradual_infill_step_height = 2\\ngradual_infill_steps = 5\\ninfil
;SETTING_3 l_pattern = cubicsubdiv\

When I slice that file I get the same thing but checking the settings in Cura - if "Cubic Subdivision" is enabled then "Gradual Infill Steps" is not enabled.  It looks like it's being used though.

 

@MariMakes could you take a look and see if you can duplicate this?  It appears that "Gradual Infill Steps" is being used even though it is disabled for Cubic Subdivision.

• With "Grid" active set the Gradual Infill Steps to 4
• Change the infill pattern to Cubic Subdivision.
• Gradual Infill Steps is disabled but it appears that the value in the box is being used during the slice.  It appears that a lot of extra motion is being generated in the gcode.