Cura 4.7.1 "Click to Resume"

[bengalih]

Cura Version

4.7.1

Operating System

Windows 11

Printer

Anet A8

Reproduction steps

This is happening on my Anet A8 with Marlin 2.1.2.4.

I believe I have seen this happen one other time (I only recently started printing) and I dismissed it. Today it happened twice on two different runs of the same print, seemingly in the exact place.

I am printing direct via USB from Cura to the printer. After about 6-7% of the print is completed (according to Cura, around 1mm built up) the print pauses with the "Click to Resume..." message. when I press the button to resume it immediately gives the message again. On second press it resumes properly.

I found other posts about this:
https://3dprinting.stackexchange.com/questions/7217/what-triggers-marlins-click-to-resume
#3994

But they all seem to indicate this was fixed in a 3.x version of Cura and they also all only reference 1.x versions of Marlin.

Actual results

I don't recall all the steps completed immediately preceding the first print. I likely did a preheat and also a manual mesh leveling. I believe I also started and then aborted the print almost immediately (during heat up) because I had the temps set wrong.
I ended up aborting the first print due to adhesion issues about 15% in, and then initiating again from Cura with a higher bed temp.
After 20-30 minutes the "Click to Resume..." appeared again, which I believe was at the same stage from the prior print.

Expected results

The expected results are that there is no pausing in the printing. Below are the first 30 or so lines of the gcode:

;FLAVOR:Marlin ;TIME:32838 ;Filament used: 25.5692m ;Layer height: 0.2 ;MINX:20.545 ;MINY:20.547 ;MINZ:0.3 ;MAXX:199.453 ;MAXY:199.453 ;MAXZ:46.9 ;Generated with Cura_SteamEngine 4.7.1 M140 S65 M105 M190 S65 M104 S195 M105 M109 S195 M82 ;absolute extrusion mode G28 ;Home G1 Z15.0 F2000 ;Move the platform G92 E0 G92 E0 G1 F1500 E-6.5 ;LAYER_COUNT:234 ;LAYER:0 M107 M204 S1000 G0 F7500 X79.57 Y42.565 Z0.3 ;TYPE:SKIRT G1 F1500 E0

After the above, there are no M commands until about line 3200:

;TIME_ELAPSED:828.331525 ;LAYER:1 M106 S127.5 ;TYPE:WALL-INNER ;MESH:Frame_Brace_Front_V1.2_Leo_N.stl

Then again at about 5300:

;TIME_ELAPSED:1596.924046 ;LAYER:2 M106 S255 ;TYPE:WALL-INNER ;MESH:Frame_Brace_Front_V1.2_Leo_N.

After that there are no more M codes until the end of the Gcode.

Add your .zip and screenshots here ⬇️

AA8_Frame_Brace_Front_V1.2_Leo_N.zip

[GregValiant]

Thanks for the report.
USB Printing is a legacy feature that is included because the older UltiMaker Original printers require it. USB Printing on the whole is glitchy (that's why UltiMaker abandoned it).
As a legacy feature, it is no longer updated. There are just too many combinations of hardware, firmware, and software out there to try and accommodate all the possible combinations.

What is happening in your case is this:
Cura sends "M105" (temperature check) every three seconds to make sure the printer is still awake and connected. If the input buffer of the printer is "almost full" the printer will truncate M105 into "M1" which is "Emergency Stop" and which automatically displays the "click to resume" message on the LCD.

You can use the SD card to print from (which is how most printers are designed to print). You can also try Octoprint (on a raspberry PI) which emulates the printer so the input buffer doesn't fill up, or the opposite problem - run dry. Running dry causes hesitation moves in the print head while the processor waits for the next line of code and that leave zits.

What you can try is to install Cura 5.8.0 which has a modified USB Printing plugin. The timing of the M105 commands was increased to (I think) 5 seconds. Although it's a lot better, it isn't prefect and you may still have the problem with certain files.
FYI - Pronterface/PrintRun had the same problem as Cura.

I'll go ahead and close this. It was (is) a well known problem. If a developer or contributor could figure out a way to fix the problem they would be an instant hero, but no one (myself included) has figured out how to do it.

[bengalih]

Thanks for the response. Just to add some more info.

• I am not a very experienced user. I have an older printer (Anet A8) that I only have less than 50 hours or so printing on. Originally when I purchased this printer 6 years ago I was using Cura 14.x something which was shipped with it. I don't recall ever having this problem and most of my prints were done via USB, however they were with the default firmware. I have not used the printer again in almost 6 years until recently.
• Since I logged this issue I have printed 10-20 hours worth of prints via USB and have not experienced the issue again.
• I have not printed the STL mentioned in the OP again (as I only needed one), so it is unclear to me if the issue was related to that specific STL. As I experienced it almost every time I printed it (I needed 4-5 tries to get it right), and have not experienced it since it would indicate that perhaps there is something specific in that print which exacerbated the issue.

As I haven't been seeing it again, and I do have the intent of moving to Octoprint, it is not much of a concern, but I still wanted to update with this info.

thanks.

[GregValiant]

The problem can be related to the firmware. Like I mentioned, there are so many possible combinations of hardware and firmware that it gets near impossible to feed the printer the gcode at a correct rate of "lines/second". The problem is also very model specific. Rounded models require more lines of gcode per second than rectangular models. A large rectangle might require a transmit rate of 1/2 line of gcode per second where a round model with a large circumference might require a transmit rate of 50 lines of gcode per second. That's a huge difference considering that the distance the nozzle travels might be the same.

Another problem can be if a user sets Cura up with different acceleration and jerk settings for the various features (outer-wall, skins, infill, etc.). The firmware on my Ender always sends a USB response when either the Accel or Jerk settings are changed. That generates A LOT of traffic from the printer to the print server, all of which can be ignored but it does take up processing cycles in the printer processor.

When printing over the USB the Arc Welder plugin that is packaged with Cura can help make a gcode file a lot smaller which means the transmit rate can be lower. Your firmware must understand the G2 and G3 arc commands for Arc Welder to work.