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?
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.
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.
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
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.
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).
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.
4.1.1 -- same EXACT problem, observed only with 4.X.X. Details: I run a Flashforge Creator Pro with a Win7/64 machine over USB (my FFCP's SD slot is broken, sorry, not an option).
Conundrum68 wrote: ↑Thu Jan 03, 2019 12:15 pm
Yep. I thought the problem was resolved in 4.0.1, but nope.
Going back to 3.1.1 until they figure it out. This is getting ridiculous.
This won't by fixed. Never version of S3D generate more g-code to accomplish some new futures/better prints and a USB - serial bridge is just to slow to keep handle it.
I just think USB printing should be just removed from S3D complete.