Blobs and zits - stuttering movement

[Gerrardh 1]

Hi All,

I've built a large CoreXY 3D Printer and I'm debugging problems that I've observed. The machine is running Duet2 Wifi board, slicing in Cura 4.7.

 

I notice that the print head frequently stops and starts on curved surfaces - just momentary pauses, but it's enough to leave behind a small blob - problem is that it does it very frequently so the prints look awful. I've researched a bunch of suggestion and none seem to fit the description all that well.

 

Here are a few observations:

• The blobs DON'T occur in consistent locations - e.g. a vertical seam, edge or otherwise. Suggesting that the problem is not related to geometry (seam in faces, curve radii, etc).
• The board is 32bit, so can handle much more complex code without buffer issues.
• Very simple geometry (straight lines) doesn't have this problem.
• Looking back over the G-Code for an arbitrary layer, I was looking for changes in the feed rate (assuming that the slicer is introducing momentary speed changes). I noticed groups of M566, G1, M566 commands which momentarily halve the jerk, and speed, before accelerating it again. To be clear- I have no way of testing whether this code relates to movement, but it looks suspicious.
• The problem didn't occur on my first 2 layers - only higher layers. The first few layers have lower speed, so speed could be a factor some how. Jerk is 12mm/s for print, 24 for travel. Accel is 600 for print and 1200 for travel.

 

The link below shows a video of the problem - the first few seconds (while printing the visible surface) is the most obvious.

 

Any suggestions?

 

 

Edited May 24, 2021 by Gerrardh

[GregValiant 1,251]

Under Mesh Fixes is a setting for Maximum Resolution.  When Creality released the definition files for the Ender 3 and Pro in Cura 4.7, the suggested Max Resolution was .025 and the print head stuttered a lot trying to deal with all the very short line segments.  When the Max Resolution is set to .5 there is no stuttering on my E3Pro.

From the RepRap Wiki M566 "Sets the maximum allowable speed change (sometimes called 'jerk speed') of each motor when changing direction".  It looks like you have set your Jerk differently for travel moves than for extrusion moves.  You may be able to get rid of all those lines of Gcode by setting the Jerk the same across the board in Cura.  That should free up the processor a bit more

Edited May 24, 2021 by GregValiant

[Gerrardh 1]

Thanks for replying.

You might be right about keeping the jerk the same = fewer lines of code, but the problem exists during a print path, so there's no travel involved (refer to attached video).

 

my maximum resolution setting is 0.5mm with maximum deviation 0.025mm.

 

Regards

[GregValiant 1,251]

Yes, I watched the video.

Another thing you could try is the Arc Welder plugin.  It calculates which G1 moves comprise an arc and creates G2/G3 moves when possible.  That can free the processor some more.  G2/G3 must be enabled in your firmware.

 

I wrote a little program that just goes in circles (using G2/G3 moves).  I was able to tune the Accel and Jerk by observing the movement.  I can set the speed as high as I want because on a circle the Accel and Jerk settings have an overwhelming effect on the speed of the print head due to the very short line segments.  On my particular machine, if I go above Accel 500 and Jerk 8, I get stuttering no matter the speed setting.  The Max acceleration is defined in M201 and the acceleration for a particular print is defined with M204.  Unfortunately, only a slice by Cura can check the effect of altering the Max Resolution.  It's a balancing act between Max Resolution, Accel and Jerk, and if you use Arc Welder - the minimum defined arc segment in the firmware.