Micro pauses in print.

[Conundrum68]

I'd like to add that I have been observing the same exact issue since upgrading to 4.0.
Makergear M2 Rev E.
Win7/64
Lenovo Core2Duo

Watching Task Manager, the CPU usage for S3D process drops to ZERO for the duration of the micro-pause.
No other processes rise up to higher CPU usage during the micro-pause.
Very frustrating because blobs have to be edited out with an X-Acto.
Anyone see a resolution for this?

[mikedehaan]

I've seen this issue when a model requires bridging and the fan speed needs to increase. The system will "micro-pause" while the fan speeds up (causing a blob) then proceed with the bridge.

I doubt this is your full issue, but my workaround was to simply make the fan run at bridge speed throughout the entire print. It may not be ideal, but it removed all micro-pauses.

[Conundrum68]

Thanks for the info. In my case,I have the fan speed pegged to 100% after the 5th layer.
Thinking about it, this pausing seems unrelated to bridging in my case.
I turned off USB going to sleep in power settings. Not sure if that will help or not.

[hamak]

Changed Minimum travel for retraction from 2 to 4mm (i think default i 3 or 5?)

I have these settings that might cause my micro pauses
wipe nozzle = 1
minimum travel for retraction = 2 (now 4)
perform retraction during wipe movement

[Porcupineshiver]

I've seen the same pause using octoprint and attempting to connect to the rpi from a different computer than what's logged in, as an FYI to anyone thinking about going that approach. Onboard storage like an SD card will perform better, as the printer will read ahead and cache accordingly. From my experiences in bigger CNC equipment it's always best to have a dedicated controller with a bare minimum level of applications open/installed on the system if you're doing something like direct numeric control, as anything that diverts the resources can cause pauses like this. On windows 10 machines they're especially prone to randomly pulling resources, processing updates and indexing when they detect an idle in user activity. With machines like lathes and mills those pauses can scrap a part if you're trying to hold a half thousandth with a polished surface on a bore for a hydraulic cylinder, or leave witness marks on milled faces where the cutter paused during a spline cut and your spindle bearings are a few years old and have a little slop.

[Conundrum68]

I'm pretty sure this problem was attributed to an erroneously-generated zero-speed move and was fixed in V4.1.0.

[jmunkki]

For people who use USB for printing, it would make sense if there was an option to minimize the gcode file. Once possible source for savings would be to eliminate unnecessary digits (you could probably do this pretty easily with a gcode filter).

For example this gcode from 4.1.1:

G92 E0.0000
G1 X17.760 Y199.550 E0.3001 F3000
G1 X17.760 Y201.760 E0.3883
G1 X10.240 Y201.760 E0.6885
G1 X10.240 Y199.950 E0.7607
G1 X10.240 Y199.550 F3000
G1 X15.240 Y199.550 F3000

Could look like this:

G92 E0
G1 X17.76 Y199.55 E0.3001 F3000
G1 X17.76 Y201.76 E0.3883
G1 X10.24 Y201.76 E0.6885
G1 X10.24 Y199.95 E0.7607
G1 X10.24 Y199.55 F3000
G1 X15.24 Y199.55 F3000

Version 4.0.1 used G92 E0, but retracts had the extra decimals:

G1 E-4.5000 F2400

could also be written as:

G1 E-4.5 F2400

The emulated serial port can be a bottleneck for USB printing, so the tighter you can make the gcode, the better the printer will perform. This is especially true if your STL file has a high number of polygons.