Print head occasionally grinds across the infill

[jrd7777 0]

I'm fairly new to 3D printing, but am able to create adequate “proto-types” for my speaker cabinet design.  I print a lot of flat, 12mm thk, "speaker cabinet" walls.  Sometimes I’ll print flat, sometimes standing the "walls" and thereby print "narrow", tall components.  I had originally thought there was some “bulid-up issue” associated with a tall configuration, but the grinding happens when I print components "flat" or "tall".  I studied the printer as it was printing and recorded the approximate layer at which the "grinding" was especially bad.  On 99.5% of the "passes" the print head lifts, translates, and restarts printing when it reaches its destination.  However, on or near layer 159 the grinding was especially bad.  So I wondered if it was in the gcode... I used the Preview tool in Cura and found this behavior.   Blue arrows point to "skipped portions of infill printing".  The red arrow points to the "print head" and in the direction of travel across the speaker wall.  You can advance the "simulation (in Cura)" and watch the print head "retreat" back to these blue arrows and "fill in" the missed lines.  During this "retreat" is when the nozzle interferes with the existing infill creating the grinding sound.  I watched this behavior happen on a few other layers and, no question the z-motors are not lifting the head.   I have to think this is a Cura, infill-gcode creation issue"?   I’m using Cura 4.8 as my slicer…  need to update at some point but this work fine for most of our applications.

 

 

I've included a second and third image to show the print head "retreats" to the blue arrows to complete the infill on this layer...

 

 

Any ideas on how to address this or compensate for this apparent "retreat and drag" issue?

[GregValiant 1,408]

I've never found it to be a problem that shows up in a print.  It can be noisy and annoying though.

Have you tried enabling Z-Hops?  The default is .2mm but I've found that at .5mm it will go over most little pimples and things that might stick up above the working Z height.  The actual setting name is "Z-Hop when retracted" so the Retraction Minimum Travel and Max Combing distance must be set correctly or a retraction won't happen and consequently a Z-Hop won't happen.

You might also try Connect Infill Lines.  I like that one because it really cuts down on the number of retractions.

[jrd7777 0]

Thx for the feedback.  It is annoying- 🙂.

 

I wonder what the conditions are that trigger the infill lines to be "skipped over, then retreat and filled in..." Complicated I'm sure! 

 

I do have Z-hop enabled and using 0.4mm.  Here:

 

 

I'll enable "Connect Infill Lines" and see if "the grind" is reduced.

[GregValiant 1,408]

Even if you were to use Lines or Grid for an infill pattern, the path will jump around a little bit in what (at first look) seems to be a dumb path.  The path is actually optimized to keep the total amount of movement down.

Another setting you should think about changing is the combing.  Right now you have it set to "Within Infill".  Try the different options.  Since it's a speaker enclosure do you really care what the top skin looks like(?) or are the walls more important.

 

 

 

[jrd7777 0]

Connect Infill Lines did not change the occurrence of the grinding.    Good feedback on "Combing" setting.  I'll do some more reading on that.  

 

To your point on optimized to "minimize" motion, I understand your comment, but not clear how skipping over infill to print (in a "fairly linear" progression), then returning back to print the skipped infill is optimal..?  Maybe this odd behavior is some artifact of that "optimization algorithm" or maybe it is just a bug...

 

Agree that so far the "grinding's" impact on part creation is minimal, just "noisy and annoying".. Thx!

[GregValiant 1,408]

The moves are supposed to be efficient.  What exactly goes into the efficiency calculation I don't know.  If Cura's planning includes the best place to be before continuing onto the next area is then it makes more sense.  I read around here someplace that figuring out the motion and optimizing it is one of the tougher aspects to programming within Cura.

 

 

 

[jrd7777 0]

yea... gotta be a thousands+ "person-hours" into that portion of the code.  My guess is opening "that box" to make changes, breaks 50 other things... 🙂  

 

Thanks again for your response and feedback.  I'll keep experimenting in an attempt to "reduce the grind..."