SOLVED Cura 4.1 pausing at each layer

[rburema 26]

We're aware of this issue: It happens for most printers that don't have maximum z speed explicitly defined in their profile. What happens then is that we instruct the printer to go 'as fast as possible' ... meaning light speed. This confuses a lot of printers (moving the extruder at relativistic speeds is probably not within normal operating parameters...), which then either pauze or just stop, instead of just moving at the maximum speed they're capable of.

 

The workaround is either to explicitly specify max z speed, manually change the profile, or disable z hopping. This will be fixed in 4.2

[rritch 1]

8 minutes ago, rburema said:

We're aware of this issue: It happens for most printers that don't have maximum z speed explicitly defined in their profile. What happens then is that we instruct the printer to go 'as fast as possible' ... meaning light speed. This confuses a lot of printers (moving the extruder at relativistic speeds is probably not within normal operating parameters...), which then either pauze or just stop, instead of just moving at the maximum speed they're capable of.

 

The workaround is either to explicitly specify max z speed, manually change the profile, or disable z hopping. This will be fixed in 4.2

Thanks for the clarification on the issue.  For now I have just added the max Z speed to each of my profiles and that has resolved the issue.  It only took a few minutes to update all of my profiles so not a big deal.

[chabes 1]

This issue was causing my hotend to pause long enough to start damaging the build surface. I had to cancel the prints, and even after cancelling, it took an odd amount of time for the printer to become responsive again and move the z-axis up and away from the build surface being melted. I couldn't figure out why it was doing it and it was driving me nuts. I often use octoprint, but tried to print straight from microSD, and both methods had the same issue. For some reason, I didn't immediately think, "hey, maybe the slicer software I just updated today might be the issue..."

 

After some googling, I couldn't find any related posts. The only reason I was able to find this post was because I saw a comment on a recent youtube video that mentioned starting and stopping on an Ender 3 Pro using Cura 4.1 as the slicer. That got me to search for "cura 4.1 stopping", which eventually brought me here. I had a hunch that pausing might have something to do with z-hopping, and as I read more posts, it became more obvious.

 

After reading the details that rburema posted, I shared the gist in the youtube comments, so other folks don't spend so much time driving themselves crazy like i did. Thanks for the details, rburema!

[PrintJan 0]

On 6/4/2019 at 2:33 PM, rburema said:

We're aware of this issue: It happens for most printers that don't have maximum z speed explicitly defined in their profile. What happens then is that we instruct the printer to go 'as fast as possible' ... meaning light speed. This confuses a lot of printers (moving the extruder at relativistic speeds is probably not within normal operating parameters...), which then either pauze or just stop, instead of just moving at the maximum speed they're capable of.

 

The workaround is either to explicitly specify max z speed, manually change the profile, or disable z hopping. This will be fixed in 4.2

I was having this issue as well, I have successfully worked around the issue with the z-hop at extremely high speed which confuses my Creality CR-X. 

However, now I have again a waiting time at the end of a layer. 

The problem is that during the waiting time, the nozzle oozes some material, which is an obstacle later on and then the part is kicked off the bed.

The part of the g-code where I expect the issue is:

 

G1 F2400 E34.94211
G0 F4350 X162.562 Y165.762
G0 X161.547 Y166.346
G0 X152.865 Y162.822
G0 X152.19 Y161.836
G0 X150.113 Y154.224
G1 F2400 E40.94211
G1 F1500 X148.459 Y155.879 E41.00047
G0 F4350 X148.413 Y155.359
G1 F1500 X150.103 Y153.669 E41.06009
G0 F4350 X149.661 Y153.545
G1 F1500 X148.367 Y154.84 E41.10576
G0 F4350 X148.326 Y154.315
G1 F1500 X149.197 Y153.444 E41.13649
G0 F4350 X148.733 Y153.342
G1 F1500 X148.3 Y153.775 E41.15176
G1 F2400 E35.15176
;MESH:NONMESH
G0 F4350 X148.489 Y163.884
G0 X147.652 Y164.873
G0 X146.465 Y165.106
G0 X145.485 Y164.476
G0 X144.857 Y163.387
G0 X142.893 Y150.169
G0 X143.075 Y148.882
G0 X143.736 Y148.214
G0 X144.806 Y147.915
G0 X164.449 Y147.113
;TIME_ELAPSED:269.949107
;LAYER:2

 

To me it looks there are a couple of G0 F2400 E... commands which extrude but without any movement. But I'm fairly new to g-code so it might be normal?

 

[burtoogle 513]

13 minutes ago, PrintJan said:

To me it looks there are a couple of G0 F2400 E... commands which extrude but without any movement. But I'm fairly new to g-code so it might be normal?

 

Yes, they are just normal retract and un-retract commands that bracket a travel move.

 

[crgrove 0]

On 5/28/2019 at 10:27 PM, wrench_bender said:

Having similar problems, except it pausing multiple times on the same layer, it stops after the skirt, and after each individual part layer is finished. Just ran an stl sliced with 4.0 and it prints fine.

Sliced with a PC and running thru Octopi.

PI3_moat.gcode 15.16 MB · 2 downloads

I've been googling the heck out of this problem and finding this, decided to add that I too have been getting MULTIPLE, lengthy, time-wasting pauses PER LAYER.
For the time being I've resorted to Slic3r PE. But I'd prefer a solution to the problem. 😕

[gr5 2,167]

This is solved.  I'm closing this thread.  The solutions are posted on the first page of this thread.  Here is a link to two of the solutions: