Cura 3.4 Pauses print after heating and again after bed leveling

[leeb65]

Application Version
3.4.0

Platform
Windows 10, version 1803

Printer
CTC Prusa i3 Pro B DIY
Modified with Marlin 1.1.8 and 3D Touch bed levelling probe.

Steps to Reproduce
Load STL, Prepare and print

Actual Results
The printer heats up bed and nozzle, then on the printer screen it says press button to resume, I then have to press the button twice and the printer goes through the bed levelling and stops again with the message Click to Resume. I press the button and it prints as usual.

Expected results
The printer should heat up, level the bed and print without interaction.

Additional Information
I have run the same print through Octopi and it runs as expected, so it is not the gcode.

PI3_Toilet_Seat_Bumper_v1-0.zip

cura_Log.zip

[alekseisasin]

Hi @leeb65, Unfortunately we do not have CTC Prusa i3 Pro B DIY in our office and I do not know how to test. Can you run the gcode from USB stick? Also, did you have same issue in Cura 3.3.1?

[leeb65]

Hi, No I did not have the problem until I updated to Cura 3.4.0 yesterday. I thought it might be my printer, so I connected it to Octopi and saved the gcode from Cura, copied it to Octopi server and set the print off from there. It ran from start to end without a problem.

[alekseisasin]

I know we did fix for the auto bed leveling (https://github.com/Ultimaker/Cura/issues/3808), but this is a different issue. (probably if you know how to search in github they were related to ticket CURA-4844)

[neowinx]

I have to report that I have this same issue with my Geeetech Prusa Pro W with BL Touch sensor.

After updating Cura to 3.4.0 it pauses at these same spots (after heating and leveling) displaying a "click to resume" message.

Would do some testing to see if this problem only occurs with marlin 1.1.8 with BLTouch. I suspect this has to be somehow related to the fact that I replaced the Z enstop with the probe sensor.

Dunno if that is the case with @leeb65

Regards

Application Version
3.4.0

Platform
Windows 10, version 1803

Printer
Geeetech Prusa i3 Pro W
Modified with Marlin 1.1.8 and 3D Touch bed levelling probe.

[leeb65]

The CTC is basically a Geeetech, I have the GT2560 Rev A+ and the similar settings in configuration.h

But it worked with the last version of Cura and all versions since 2.6, bar one version that didn't work at all.

[maikbooehme]

hi all, I have the same issue with an AM8 and Marlin 1.1.8 .... so thats not printer specific and started after the upgrade to CURA 3.4 what did you change in the code ?

maybe its related to the start code which is interpreted different
M109 S{material_print_temperature} ;Wait for extruder to reach temp before proceeding

[fieldOfView]

These are the exact changes between Cura 3.4 and 3.3 in the USB Printing plugin:

diff --git a/plugins/USBPrinting/USBPrinterOutputDevice.py b/plugins/USBPrinting/USBPrinterOutputDevice.py
index 74c24e2..00eb2f0 100644
--- a/plugins/USBPrinting/USBPrinterOutputDevice.py
+++ b/plugins/USBPrinting/USBPrinterOutputDevice.py
@@ -18,7 +18,7 @@ from .avr_isp import stk500v2, intelHex
 from PyQt5.QtCore import pyqtSlot, pyqtSignal, pyqtProperty

 from serial import Serial, SerialException, SerialTimeoutException
-from threading import Thread
+from threading import Thread, Event
 from time import time, sleep
 from queue import Queue
 from enum import IntEnum
@@ -82,8 +82,16 @@ class USBPrinterOutputDevice(PrinterOutputDevice):

         self.setConnectionText(catalog.i18nc("@info:status", "Connected via USB"))

-        # Queue for commands that need to be send. Used when command is sent when a print is active.
+        # Queue for commands that need to be sent.
         self._command_queue = Queue()
+        # Event to indicate that an "ok" was received from the printer after sending a command.
+        self._command_received = Event()
+        self._command_received.set()
+
+    ## Reset USB device settings
+    #
+    def resetDeviceSettings(self):
+        self._firmware_name = None

     ##  Request the current scene to be sent to a USB-connected printer.
     #
@@ -228,6 +236,8 @@ class USBPrinterOutputDevice(PrinterOutputDevice):
         self._baud_rate = baud_rate

     def connect(self):
+        self._firmware_name = None # after each connection ensure that the firmware name is removed
+
         if self._baud_rate is None:
             if self._use_auto_detect:
                 auto_detect_job = AutoDetectBaudJob(self._serial_port)
@@ -259,23 +269,24 @@ class USBPrinterOutputDevice(PrinterOutputDevice):

     ##  Send a command to printer.
     def sendCommand(self, command: Union[str, bytes]):
-        if self._is_printing:
+        if not self._command_received.is_set():
             self._command_queue.put(command)
-        elif self._connection_state == ConnectionState.connected:
+        else:
             self._sendCommand(command)
-
     def _sendCommand(self, command: Union[str, bytes]):
-        if self._serial is None:
+        if self._serial is None or self._connection_state != ConnectionState.connected:
             return

         if type(command == str):
-            command = (command + "\n").encode()
+            command = command.encode()
         if not command.endswith(b"\n"):
             command += b"\n"
         try:
+            self._command_received.clear()
             self._serial.write(command)
         except SerialTimeoutException:
             Logger.log("w", "Timeout when sending command to printer via USB.")
+            self._command_received.set()

     def _update(self):
         while self._connection_state == ConnectionState.connected and self._serial is not None:
@@ -286,13 +297,32 @@ class USBPrinterOutputDevice(PrinterOutputDevice):

             if self._last_temperature_request is None or time() > self._last_temperature_request + self._timeout:
                 # Timeout, or no request has been sent at all.
+                self._command_received.set() # We haven't really received the ok, but we need to send a new command
+
                 self.sendCommand("M105")
                 self._last_temperature_request = time()

+                if self._firmware_name is None:
+                    self.sendCommand("M115")
+
             if b"ok T:" in line or line.startswith(b"T:") or b"ok B:" in line or line.startswith(b"B:"):  # Temperature message. 'T:' for extruder and 'B:' for bed
                 extruder_temperature_matches = re.findall(b"T(\d*): ?([\d\.]+) ?\/?([\d\.]+)?", line)
                 # Update all temperature values
-                for match, extruder in zip(extruder_temperature_matches, self._printers[0].extruders):
+                matched_extruder_nrs = []
+                for match in extruder_temperature_matches:
+                    extruder_nr = 0
+                    if match[0] != b"":
+                        extruder_nr = int(match[0])
+
+                    if extruder_nr in matched_extruder_nrs:
+                        continue
+                    matched_extruder_nrs.append(extruder_nr)
+
+                    if extruder_nr >= len(self._printers[0].extruders):
+                        Logger.log("w", "Printer reports more temperatures than the number of configured extruders")
+                        continue
+
+                    extruder = self._printers[0].extruders[extruder_nr]
                     if match[1]:
                         extruder.updateHotendTemperature(float(match[1]))
                     if match[2]:
@@ -306,17 +336,23 @@ class USBPrinterOutputDevice(PrinterOutputDevice):
                     if match[1]:
                         self._printers[0].updateTargetBedTemperature(float(match[1]))

+            if b"FIRMWARE_NAME:" in line:
+                self._setFirmwareName(line)
+
+            if b"ok" in line:
+                self._command_received.set()
+                if not self._command_queue.empty():
+                    self._sendCommand(self._command_queue.get())
+                if self._is_printing:
+                    if self._paused:
+                        pass  # Nothing to do!
+                    else:
+                        self._sendNextGcodeLine()
+
             if self._is_printing:
                 if line.startswith(b'!!'):
                     Logger.log('e', "Printer signals fatal error. Cancelling print. {}".format(line))
                     self.cancelPrint()
-                if b"ok" in line:
-                    if not self._command_queue.empty():
-                        self._sendCommand(self._command_queue.get())
-                    elif self._paused:
-                        pass  # Nothing to do!
-                    else:
-                        self._sendNextGcodeLine()
                 elif b"resend" in line.lower() or b"rs" in line:
                     # A resend can be requested either by Resend, resend or rs.
                     try:
@@ -326,18 +362,31 @@ class USBPrinterOutputDevice(PrinterOutputDevice):
                             # In some cases of the RS command it needs to be handled differently.
                             self._gcode_position = int(line.split()[1])

+    def _setFirmwareName(self, name):
+        new_name = re.findall(r"FIRMWARE_NAME:(.*);", str(name))
+        if  new_name:
+            self._firmware_name = new_name[0]
+            Logger.log("i", "USB output device Firmware name: %s", self._firmware_name)
+        else:
+            self._firmware_name = "Unknown"
+            Logger.log("i", "Unknown USB output device Firmware name: %s", str(name))
+
+    def getFirmwareName(self):
+        return self._firmware_name
+
     def pausePrint(self):
         self._paused = True

     def resumePrint(self):
         self._paused = False
+        self._sendNextGcodeLine() #Send one line of g-code next so that we'll trigger an "ok" response loop even if we're not polling temperatures.

     def cancelPrint(self):
         self._gcode_position = 0
         self._gcode.clear()
         self._printers[0].updateActivePrintJob(None)
         self._is_printing = False
-        self._is_paused = False
+        self._paused = False

         # Turn off temperatures, fan and steppers
         self._sendCommand("M140 S0")
@@ -395,4 +444,4 @@ class FirmwareUpdateState(IntEnum):
     unknown_error = 3
     communication_error = 4
     io_error = 5
-    firmware_not_found_error = 6
\ No newline at end of file
+    firmware_not_found_error = 6
diff --git a/plugins/USBPrinting/USBPrinterOutputDeviceManager.py b/plugins/USBPrinting/USBPrinterOutputDeviceManager.py
index 58b6106..f72afd9 100644
--- a/plugins/USBPrinting/USBPrinterOutputDeviceManager.py
+++ b/plugins/USBPrinting/USBPrinterOutputDeviceManager.py
@@ -42,11 +42,19 @@ class USBPrinterOutputDeviceManager(QObject, OutputDevicePlugin):
         # Because the model needs to be created in the same thread as the QMLEngine, we use a signal.
         self.addUSBOutputDeviceSignal.connect(self.addOutputDevice)

+        Application.getInstance().globalContainerStackChanged.connect(self.updateUSBPrinterOutputDevices)
+
+    # The method updates/reset the USB settings for all connected USB devices
+    def updateUSBPrinterOutputDevices(self):
+        for key, device in self._usb_output_devices.items():
+            if isinstance(device, USBPrinterOutputDevice.USBPrinterOutputDevice):
+                device.resetDeviceSettings()
+
     def start(self):
         self._check_updates = True
         self._update_thread.start()

-    def stop(self):
+    def stop(self, store_data: bool = True):
         self._check_updates = False

     def _onConnectionStateChanged(self, serial_port):
@@ -65,10 +73,11 @@ class USBPrinterOutputDeviceManager(QObject, OutputDevicePlugin):
             if container_stack is None:
                 time.sleep(5)
                 continue
+            port_list = []  # Just an empty list; all USB devices will be removed.
             if container_stack.getMetaDataEntry("supports_usb_connection"):
-                port_list = self.getSerialPortList(only_list_usb=True)
-            else:
-                port_list = []  # Just use an empty list; all USB devices will be removed.
+                machine_file_formats = [file_type.strip() for file_type in container_stack.getMetaDataEntry("file_formats").split(";")]
+                if "text/x-gcode" in machine_file_formats:
+                    port_list = self.getSerialPortList(only_list_usb=True)
             self._addRemovePorts(port_list)
             time.sleep(5)

[ianpaschal]

We just discussed this as a team. Unfortunately we don't have these printers to test with so the only way we can make any fixes/improvements is to know exactly what part of the gcode needs to be changed.

[maikbooehme]

So I checked it again and the issue is within the start Gcode of the printer.
If the following is set, then the system is waiting for a click to resume printing before autobed leveling
M109 S{material_print_temperature} ;Wait for extruder to reach temp before proceeding
But the temperature has already been reached.

[leeb65]

So this being the first of the gcode processing sections that needs to be addressed, but it would be the code that handles both the bed and the nozzle as I have to press twice before it will level the bed. The second is the code that starts the print after bed levelling, which is M117.

[maikbooehme]

and from my point of view its, changing: sometimes you need to press only once and then 2 times as Leeb65 has described it. in the mean time I also saw a break , when you click something in the menu of cura.... like opening the bug report.... it looks like that CURA is sending a pause over the USB connection.

[reforket]

I have the same issue.
Printer: Flyingbear Tornado
Firmware: Marlin 1.1.8 with BLTouch

[maciekbaczmanski]

Hi! I have the same issue.
Printer: Tevo Tarantula with mks gen L board and sn04 probe
Firmware: Latest Marlin downloaded from here: https://github.com/JimBrown/MarlinTarantula

[leeb65]

I have stepped back to 3.3.1 until this bug is fixed, if it does get fixed.

[sevenmead]

Same for me when I upgraded to 3.4 on a rigidbot upgraded with arduino ramps. Was printing flawlessly and the upgrade cause massive issues. I'll downgrade. Can't believe how hard it was for me to find people with a similar issue. I tried every combination of words. Found this page after 4 or 5 long attempts spread over the last 3 weeks.

[CodeOptimist]

Kudos on the other improvements in 3.4. 👍😉 The pausing is causing me issues as well. My end g-code heats up the bed extra for a minute, I've found it makes a huge difference in releasing the print. But 3.4 broke it. ☹

[tre4b]

Okay. I have been using CURA 3.4 for a while and have a Geeetech i3 running 1.1.9 now but 1.1.8 up to a while ago and I've not seen these issues. Until today.

Today I had my first go with something other than PLA (PETG) and used a higher nozzle and bed temperature. I then got this message and had to press to start the print. When this finishes (and it is currently printing very badly) I will try again with PLA and see if the message goes away.

[tre4b]

And the result is. The printer is happily printing PLA without me having to press a key. There is some correlation between material or temperature going on here.

[CodeOptimist]

For me it's M190 S<bed temperature>. @maikbooehme above mentioned the same but M109 for extruder. Didn't pause before 3.4, just waited for the temperature as described.

[zinenu]

can someone fix this fucking problem? it really shouldnt be that difficult. i swear the cura developers are some of the most incompetent people on this planet. shit ass software can't even handle a thermal runaway without crashing.

[leeb65]

It's quite obvious the problem is at the end of the heating of bed and hotend, also just before printing, a pause signal is sent to the printer. Remove the pause code and voila it should print without pausing.

The other alternative is to use one of the other slicers with print software or Octopi. It cannot be difficult to compare the code from v3.3 with the code from 3.4 and see the differences, there I loads of software out there. I would not get away with releasing a piece of software at work that doesn't do it's job properly, I cannot say 'oh it won't work in Chrome so you can't use that.', we even have a hat for the 'it works on my machine'.

[fieldOfView]

Hostility gets you nowhere here. None of the developers here owes you anything.

Ultimaker developers develop Cura for Ultimaker printers, because they are paid by Ultimaker. Other, mostly volunteer developers, like me, develop Cura because it helps our own situation, and because we derive some “fun” from it. Do you think your saying we are stupid or threatening to use other software contributes in any way to that “fun” or my ability to use Cura myself? Spoiler-alert: no, it doesn’t.

As for your suggestion to just look at what changed in USBPrinting between 3.3 and 3.4, that is exactly what I did above. No, there’s no pause being sent.

Cura does not work for you? Sorry to hear that, come talk to us in a civilized way. Can’t do that? Then PLEASE go use some other software. I owe you nothing, you owe me nothing.

[leeb65]

I'm sorry, if making a suggestion to someone to use another slicer offends you? Is it not better than me swearing at you for it not being fixed?

I have talked to you and others have, one person swears and you take offence to a suggestion.

[CodeOptimist]

fieldOfView may have mistaken you for zinenu

[ianpaschal]

^ I think so too, although @leeb65 you're polite but also extremely patronizing.

It cannot be difficult to compare the code from v3.3 with the code from 3.4 and see the differences, there I loads of software out there.

See the differences, sure. Understand why exactly something changed, not easy. Also has nothing to do with what other software is out there.

I would not get away with releasing a piece of software at work that doesn't do it's job properly

Good for you and the world thanks you for it. We also do extremely extensive testing on Cura but bugs still arise. ;)

[tre4b]

Getting back to the underlying problem. I can report that this went away for me, I no longer have the problem.

That said previously I had a mechanical problem with heat leaking past the barrier to the "cold" end. This was only happening above PLA temps, this was exactly when I was getting the pausing described above. I changed the cooling of the cold end and both my extrusion problem and this error went away. Could this be some sort of bizarre thermal runaway warning? Sounds far fetched but all works fine for me now.

[alekseisasin]

By the way. At the beginning of the conversation was mentioned that main difficult for Cura team is that we do not have the 3Dprinter where the issue has occurred (_Unfortunately we don't have these printers to test ..._).
You can help us to find the problem if you would carefully identify the problem ( to be sure that it is not any mechanical issue), find the place in GCode and describe what was before and now -> check the message from fieldOfView )
@zinenu , Thank you for helping us.

[Noize4U]

It only happens when using Cura 3.4 and Marlin 1.1.9(maybe1.1.8?)I have a generic Delta/Kossel. I have not tested different Arduino/Ramps setting. When just slicing in Cura and using saved G-code in printrun or octopi I do not get «click to resume» when using those as printcontroller.

[fieldOfView]

Note that Cura never sends a pause command (M0, M25 or M226) unless it is in the gcode. Even when pressing the pause button, Cura stops sending new commands to the printer until you press resume, but it does not send a pause command. If you press pause in Cura, you cannot resume it from the printer and the printer will _not_ show the "press button to resume" message.

So it looks like the firmware is not actually being paused by Cura, but it is responding to something by pausing. I don't know enough about different firmwares to know what could cause the printer to pause. From the reprap g-code guide, it looks like there are things like auto save on loss of power configurations that can pause a print (see M911), motor stall detection can pause a print (see M915), etc.

[leeb65]

@Noize4U I was going to upgrade to marlin 1.1.9 and see if it makes a difference. However marlin 2 is in Alpha or Beta and that may make a difference. Maybe even step back to marlin 1.1.7 and see if that makes a difference.

If you slice the print in Cura 3.4 and then print it with Octopi, it prints without pausing.

What firmware does the Ultimaker use?

@ianpaschal I am a developer too and finding these bugs is not easy, but a suggestion that may have been overlooked is not patronising. It's just a shame it's written in Python.

[leeb65]

This is the g-code from 2 different versions of Cura:
;FLAVOR:Marlin
;TIME:5118
;Filament used: 2.99101m
;Layer height: 0.1
;Generated with Cura_SteamEngine 3.4.0
M190 S70
M104 S220
M109 S220
M82 ;absolute extrusion mode
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
M114
G29
G1 Z15.0 F9000 ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F9000
M117 Printing...
G92 E0
G1 F1500 E-6.5
;LAYER_COUNT:14
;LAYER:0
M107

And the earlier version:

;FLAVOR:RepRap
;TIME:748
;Filament used: 0.447819m
;Layer height: 0.1
;Generated with Cura_SteamEngine 3.2.1
T0
M190 S70
M104 S220
M109 S220
M82 ;absolute extrusion mode
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 ;
M114 ;
G29 ;
G1 Z15.0 F9000 ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F9000
;Put printing message on LCD screen
M117 Printing...
M83 ;relative extrusion mode
;LAYER_COUNT:14
;LAYER:0
M107

I changed nothing in the settings, I just upgraded the software, but looking at the g-code note the flavour.

Both print fine in octopi.

[Noize4U]

When I printed a RAFT the printer paused (click to resume) 3 times for no apparent reason. Sometimes when starting a print (when using Cura3.4 and Marlin 1.1.9 And after printing from another program) printhead goes hiwire and starts the print 5-10 cm above the plate.

[CodeOptimist]

@Noize4U I had that last part too. No idea if it's related.

[maikbooehme]

hi all,

I just did a new test with marlin 1.1.9 and Cura 3.4.1 and now after the bed heating and before/during the hotend is heating I already see the "click to resume" message .

And now after the 1st layer, the 2nd message "click to resume" .

Best regards
Maik

[maikbooehme]

I have an Idea, could it be that this issue is caused by the setting of the printer when the machine setting "heated bed" was not selected, because the values for the plate temperature are not listed under material.

I'm just running an other test, where I selected the option "heated bed" .

Results: its not the issue ;-) still seeing the "click to resume" messages

[leeb65]

@maikbooehme I didn't bother with 3.4.1, I reverted back to 3.3.1 and stayed with that and that works fine, I will at some point upgrade the firmware on my printer to marlin 1.1.9.

On another note, I wonder if it would have the same issue with the Repetier firmware, or if it's just related to marlin.

As I already asked before: What firmware does the Ultimaker use? Is it proprietary firmware or is it Marlin.

[fieldOfView]

Ultimaker uses a fork of Marlin from quite a while ago. But Ultimaker does not use USB printing anymore, which explains why USB printing is not getting any attention from Ultimaker devs.

[maikbooehme]

I confirm, going back to 3.3.1 and the issue is not seen ... so for me its a code issue with in 3.4 and 3.4.x

Maybe its related to something where the temperature is running away and the software is waiting to reach the target temperature, which is then initiating the pause state.

[Gazza-USA]

I see the same issue having just upgraded to Marlin 1.2.1. I did not see this before (and I was still using Cura 3.4.1) so it looks like this is an interaction issue. I also notice that since the temp controls are now PID on Marlin 1.2.1 that the temperature is not being reported up to Cura. So I'm assuming that Cura times out because it doesn't get any status from the Printer about the Temperatures. I have files a bug report with the Marlin code guys as I suspect this is where the error is. M105 reports correctly though.

Incidentally to fix this, if you do a PRE-HEAT the problem does not occur. So I really suspect this is a timeout on temperature reporting. I notice that M155 is not supported for some reason (Auto Temperature Reporting - Maybe Cura relies on this ?).

I will note that on Cura 3.3.0 I don't see the temperatures being updated as the Bed and Nozzle are heating up however once they reach temperature the print resumes. When it resumes it gets the wrong estimated time left value, so this indicates to me that there is some wait condtion that incorrectly gets teh temperatures whilst waiting and then rolls through the loop when final temperature is met and then continues with the wrong timer info. The timer gets recalculated later and resumes as normal. This makes Cura 3.3.0 more usable but it's still an issue. I enabled M155 gcode and this hasn't solved the issue for either 3.3.0 or 3.4.1.

When the software is idle it reports the temperatures correctly.

I'm using an ENDER 3 BTW.,

[HuguesDug]

OS:
Windows 10

Cura version:
3.4.1

Printer:
Anet A8 (upgraded with Marlin Firmware 1.1.8)

To reproduce:
Open Cura,
Load a model,
Click print via USB

Defaut:
The bed and nozzle are heated, printer bed leveling is done and the printer won't print.
Temperature is not updated in cura on "monitor" during heating phase
Task completion pencentage is crazy (130% for example or 85% but with nothing printed)

Workaround:
I removed version 3.4.1 and went back to 3.3.0
Temperature is still not displayed while warming up, pencentage is also not OK... but the printer will print after bed leveling.

Previous version:
I used to use version 3.1 for a long time with no issue.

[blueeagle69]

I know this doesn't help, but I have the same. Whenever it sees a Gcode command for temperature in the start Gcode it sends a pause to the printer. I mostly use Cura, slicing to the SDcard, so a small annoyance. I'm normally stood over my printer during the first layer anyway.

[Gazza-USA]

I moved to Repetier and that seems to work. It uses the Cura engine for slicing. Looks like it's a Cura issue.

[scooper1]

i am getting this click to resume...
it happens about a average once every 20 minutes

[DarkShadowsX5]

Same problem for me after recent Cura update.
Cura 3.4.1
Printer: Prusa i3 acrylic clone( < name doesn't matter as it could be called flexible noodle i5 and have the same hardware)
Control board: a MKS BASE v1.5 w/ RAMPS 1.4
Marlin: v1.1.4

Problem: printer heats up (click to resume) printer levels (Click to resume)
printing from SD card has a click to resume too and i just hate using sd card printing anyway. its much easier to use USB. I dont have an octopi compatible board so that's out of the question.

startup code:
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F9000 ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F9000
M117 Printing...
M75 ;Start Print Timer

i dont see any pauses.... i'm going to have to downgrade Cura and deal with the annoying "upgrade available" popup. for now.

[Sam0Park]

It seems like the problem comes from combination of Cura 3.4 and some firmwares which is not reporting current temperature.
Cura 3.4.1
Marlin 1.1.8
I just found out, If I set the initial layer temperature different than the default temperature,
it pauses in Cura's USB printing mode.
Printing from SD card does not make the pause.
When I restored the initial layer temperature to the same as the default temperature,
Cura does not pause.

I hope we can fix this soon.

Thanks

[nallath]

We have a pull request open that should resolve it, but we haven't gotten around to testing it.

[fieldOfView]

If you mean #4369, then I would say "We have a pull request open that ~should~ could - in theory - resolve it,"

The changes in that PR are fairly small, so if you feel adventurous you may help us test if it fixes this issue too: https://github.com/Ultimaker/Cura/pull/4369/files

[fieldOfView]

Interesting. I have just updated another printer (BLACKBELT 3D) to Marlin 1.1.9, and now I am getting the same "Click to resume" messages, _when printing from SD!_

[fieldOfView]

It looks like the problem is that Marlin does not like being polled continuously with M105 gcodes while it is preheating. During actions such as M109 and M190, Marlin reports that it is busy but Cura continues to send M105 lines. I think Marlin pauses because it has detected that commands were lost because the buffer filled up.

This should be fixed in #4487.

[alekseisasin]

What I can do, make a new build(from #4487 ) and we can test together to make sure that it is solved. Do we have volunteers?

[joba-1]

yes.

I’d gladly test app images on open suse leap with an anycubic kossel pulley using marlin 1.1.9.

Currently I see the confirmation request at the beginning of each print and sometimes inbetween (last 2 prints ruined, one after exactly 2.5 layers of a 5cm square, the other much later, after printing height ca. 1cm

[alekseisasin]

@joba-1 , This is the link.
https://wetransfer.com/downloads/91a7b4bcfed5347564d74ef9366e8b5620181005142210/74607f7118e23ff5eb9c3482b2cff05f20181005142210/4138be

Be aware it is NOT STABLE Cura build and use it only for testing purposes.

[joba-1]

@alekseisasin Thanks! But unfortunately you uploaded a win64 build. As I wrote, I use open suse leap, (edit: i.e. linux, in case thats not obvious) so this build is very stable ... in not working at all :)

[Sanguium]

@joba-1 , This is the link.
https://wetransfer.com/downloads/91a7b4bcfed5347564d74ef9366e8b5620181005142210/74607f7118e23ff5eb9c3482b2cff05f20181005142210/4138be

Be aware it is NOT STABLE Cura build and use it only for testing purposes.

So just tried this build, a bit of background:
Anet A8 - Marlin 1.1.9
Cura 3.3.1 prints fine, but temps won't update while heating.
Cura 3.4-3.5 temp still don't update, print pauses after heating when resumed prints fine.

With this 0.0.0 build temps update while heating but it still pauses after heating, and it won't print after resumed, it stops as soon it touches the bed and looks like it's trying to move like one step each 5 seconds, at that point I aborted the print. Tried with the same 3.5 profile I had and creating a new one from scratch, same result.

[fieldOfView]

@leeb65 @neowinx and @hughsie, could you please test the build shared by @alekseisasin above?

~@joba-1~ @Sanguium, just to rule out slicing issues (which we are not interested in for this build), could you slice an object with 3.4 or 3.5, save the gcode and try sending it with the private build?

[joba-1]

Hi Aldo

I told it on github, but cant see my answer in this mail thread, so you
probably have not seen it:
I cannot test the private build, since it is not linux.

What I could do and I already planned to do is generate gcode on 3.5 and
print from SD and from Cura 3.3.
Also I could generate gcode on 3.3 and try to print ih with 3.5 if that
helps?

Still, testing time is limited, because Cura destroys my other serial

connections, so I cannot use it in parallel to other stuff.

iphone so i typo

[fieldOfView]

@joba-1, it is a case of mistaken identity, I meant to ping @Sanguium

[Sanguium]

@fieldOfView Sliced with 3.5 and gcode loaded into test build, same scenario as before, heats, pauses and doesn't print after resumed.

Edit: loaded that same gcode in 3.3.1 and it's printing fine, just the temps won't update while heating like before.

[joba-1]

Fwiw:

I could finally manage to build Cura myself for openSUSE linux from source (github master).
Several small prints done with this code work just fine with no pause, while the 3.5 appImage never worked. Temperature updates work during heating and during the actual print.

In case it makes a difference: I had to use another printer model as base model. In 3.5 I used DeltaBot, now I use Kossel Pro.
For some reason I could not select filament with diameter 1.75 with the DeltaBot, although I changed it in the machine settings.
This (I guess) changed the Start G-Code from

G28 ;Home
G1 Z15.0 F6000 ;Move the platform down 15mm

;Prime the extruder
G92 E0
G1 F200 E3
G92 E0

to

; info: M303 E0 S200 C8 ; Pid auto-tune 

M140 S{material_bed_temperature}; Start heating up the base
G28 ; Home to top 3 endstops
; Autolevel and adjust first layer
; Adjust this value to fit your own printer!  (positive is thicker)
; This default value is intentionally very high to accommodate the
; variety of print heads used with this printer.  Many of you will
; need tiny values like Z0 or Z0.1.  Use feeler gauges to dial this
; in as accurately as possible.
G29 Z10

; Squirt and wipe ;
M109 S220 ; Wait for the temp to hit 220
G00 X125 Y-60 Z0.1 ;
G92 E0 ;
G01 E25 F100 ; Extrude a little bit to replace oozage from auto levelling
G01 X90 Y-50 F6000 ;
G01 Z5 ;

; Set the extruder to the requested print temperature
M104 S{material_print_temperature}

I didn't test if that makes a difference.

The only code difference I see in the USBPrinting plugin since 3.5 is some pattern matching:

diff --git a/plugins/USBPrinting/USBPrinterOutputDevice.py b/plugins/USBPrinting/USBPrinterOutputDevice.py
index 4ceda5287..36c532118 100644
--- a/plugins/USBPrinting/USBPrinterOutputDevice.py
+++ b/plugins/USBPrinting/USBPrinterOutputDevice.py
@@ -326,8 +326,8 @@ class USBPrinterOutputDevice(PrinterOutputDevice):
                 if self._firmware_name is None:
                     self.sendCommand("M115")

-            if (b"ok " in line and b"T:" in line) or line.startswith(b"T:") or b"ok B:" in line or line.startswith(b"B:
"):  # Temperature message. 'T:' for extruder and 'B:' for bed
-                extruder_temperature_matches = re.findall(b"T(\d*): ?([\d\.]+) ?\/?([\d\.]+)?", line)
+            if re.search(b"[B|T\d*]: ?\d+\.?\d*", line):  # Temperature message. 'T:' for extruder and 'B:' for bed
+                extruder_temperature_matches = re.findall(b"T(\d*): ?(\d+\.?\d*) ?\/?(\d+\.?\d*)?", line)
                 # Update all temperature values
                 matched_extruder_nrs = []
                 for match in extruder_temperature_matches:
@@ -349,7 +349,7 @@ class USBPrinterOutputDevice(PrinterOutputDevice):
                     if match[2]:
                         extruder.updateTargetHotendTemperature(float(match[2]))

-                bed_temperature_matches = re.findall(b"B: ?([\d\.]+) ?\/?([\d\.]+)?", line)
+                bed_temperature_matches = re.findall(b"B: ?(\d+\.?\d*)  ?\/?(\d+\.?\d*) ?", line)
                 if bed_temperature_matches:
                     match = bed_temperature_matches[0]
                     if match[0]:

[alekseisasin]

Right, there are not many changes in "pattern matching:". From the beginning we do not understand how it might affect this issue, you can try to replace the code from the 3.4 branch and see the difference.

[fieldOfView]

From the beginning we do not understand how it might affect this issue

What? It is not rocket science.

During some operations, such as preheating, the printer responds to new commands with "echo:busy". While it is buys, it does send temperature messages, but these are not prepended with an "ok", because the "ok" is supposed to show that a command was received and executed. So the two patches I wrote do the following:

• the pattern matching no longer looks for "ok" messages, but looks for temperature updates (this fixes the temperature updating while the printer is preheating)
• once the printer has said that it is busy, stop asking for temperature updates until the next "ok" is received (this prevents the serial buffer overflowing while preheating)

[alekseisasin]

"What? It is not rocket science." I meant, how come that change does not work for other printers if there is no special change.

[yodor]

I have the same issue with click to resume - delta printer with marlin 1.1.9 and cura 3.5.0-beta
Shows click to resume randomly.
My solution was to extract the AppImage files then replace the USBPrinterOutputDevice.py from tree
cb24d58
(I did not manage to run from master build because of some issues with material not found)
All goes well for now thanks :)

[fieldOfView]

It seems that #4487 may have fixed the "press to continue" after preheating, but it is still occurring during the print.

To update the temperatures in the monitor, Cura sends M105 pings every 2 seconds. It seems that if this is done during a print without waiting for an "OK" from the printer, the serial buffer on the printer may still overflow eventually (causing Marlin to complain/pause). I will update #4487 with a fix for that.

[yodor]

@fieldOfView you are right, I tried a long print last night and it happened during printing atleast once.

[fieldOfView]

@yodor, I have updated my branch, it would be great of you could test it again:
https://github.com/Ultimaker/Cura/blob/777470db7f06eb64d70e73468d195ab1140eba42/plugins/USBPrinting/USBPrinterOutputDevice.py

[yodor]

@fieldOfView just tried - cura wont recognize the printer. I usually reset printer after starting cura to be able to recognize it but with this file it wont recognize it at all - maybe need more time to initialize ?

[fieldOfView]

I have made some more fixes in PR #4487

To facilitate testing, I have created a plugin for Cura 3.5 that patches the USB Printing plugin. ~This plugin for Cura 3.5.x can be downloaded here:~
~http://files.fieldofview.com/temp/USBPrintingPatch-v5-2018-10-19T12_56_52Z.curapackage~
After downloading, drop the file into a running Cura 3.5.x and restart Cura.

[fieldOfView]

Hmm, wait, that plugin is not (yet) working

[fieldOfView]

Here's a new version of the patching plugin for Cura 3.5:
http://files.fieldofview.com/temp/USBPrintingPatch-v5-2018-10-19T12_56_52Z.curapackage

@yodor, the last version you tried did not work because I merged in changes to master which don't work in Cura 3.5 yet. If you want to patch your Cura without the plugin, try this branch: https://github.com/fieldOfView/Cura/blob/fix_marlin_press_to_resume_35/plugins/USBPrinting/USBPrinterOutputDevice.py

[Sanguium]

@fieldOfView that's the one, with that version it worked for me in 3.5.1, no pauses and temperature updates while heating. I copied the .py file over the one I had.
Only problem is while heating the progress percent is incorrect, it went to something like 580% while heating for a 2 minute print that took ~10 minutes to heat up.

[yodor]

Hey @fieldOfView Thank you very much. This one works very well for me too. I'll try longer print and post here if there is something unusual.

[fieldOfView]

The fixes have now been merged into master, so they should be part of the next Cura release. Thanks for testing!

[diegopradogesto]

We have this fix already in our master branch but we couldn't do a proper test. We hope it is fixed but I would like to have some of you to test with one of our daily builds. If you are willing to help us a bit, please let me know if you use Windows, Linux or macOS and I can send a link to download the file.

[CodeOptimist]

Windows 10 here. I would be happy to test the circumstances that consistently pause my own prints beginning in 3.4 (a burst of bed heat with M190 S<bed temperature> in my ending g-code). Would be nice to print a bit closer knowing it'll still come off easily at the end thanks to this trick, just as I was doing before. 😉 This is a good time... about to print a succession of small prototypes.

[Sanguium]

@diegopradogesto I can print a couple tests with the new version, I have Windows 10.

[diegopradogesto]

Hi @CodeOptimist and @Sanguium here you can download the nightly build: https://we.tl/t-tcnieR5WGR (available for 7 days)

Please try it and let as know if this fix the issue.

[alfem]

We have this fix already in our master branch but we couldn't do a proper test. We hope it is fixed but I would like to have some of you to test with one of our daily builds. If you are willing to help us a bit, please let me know if you use Windows, Linux or macOS and I can send a link to download the file.

Hi! I can help with testing in Linux 64bits. Last cookie cutter I printer yesterday stopped six times in one hour.

If you send me the test version I will try it today.

[diegopradogesto]

Here you are @alfem : https://we.tl/t-kmFIQQU17e

[alfem]

Here you are @alfem : https://we.tl/t-kmFIQQU17e

I made a little test with another cookie cutter (1h 35minutes) and my Tevo Tarantula worked perfectly!

No stops at the begining nor in the middle of the printing process. I will go on with tests this weekend and report any issue.

[yodor]

Hi @diegopradogesto - I've also tested but it won't fork for me for other reason. While there is no 'click to resume' before print, only the first layer was printed from the model so I can not test longer prints. Also the remaining print time counter label starts from 130%.

[Sanguium]

@diegopradogesto It worked fine for me, no pauses and temperature updates while heating, still the progress % goes over 100% while heating and then goes back when the actual print starts, but that's a minor issue.

[nics21212]

Here you are @alfem : https://we.tl/t-kmFIQQU17e

I made a little test with another cookie cutter (1h 35minutes) and my Tevo Tarantula worked perfectly!

No stops at the begining nor in the middle of the printing process. I will go on with tests this weekend and report any issue.

This works great with my A10 also, no "click to resume" before printing

[joba-1]

My printer has temperature issues so I cannot do long tests right now, but I did a short test on the linux version: small prints are fine without pause. Thank you!

[HuguesDug]

Tested today the Cura 3.6 with the fixes : The problem is still partially there.

Now, display shows correct temperature, but you still need a click to resume on the screen after probing the bed so the printer starts to print. Then it goes without any problem.

Windows 10, Cura 3.6, Anet A8 with Marlin 1.8

[leeb65]

Mine is now working perfectly, thanks guys great job.
@HuguesDug: I have updated my Marlin to 1.9 and I have no more problems.

[jacobjennings]

Seeing this issue with original Tevo Tarantula with marlin 2.0