Running Marlin 220.127.116.11 on Cura 3.2.16 I'm seeing the same issue. Here is a portion of the out put with the last two lines being the occurrence of the pause:
< [10:45:57] Error:No Checksum with line number, Last Line: 3182 < [10:45:57] USBPrinterOutputDevice: Resending from: 3183 < [10:50:36] Error:checksum mismatch, Last Line: 9874 < [10:50:36] USBPrinterOutputDevice: Resending from: 9875 < [10:52:11] Error:checksum mismatch, Last Line: 12131 < [10:52:11] USBPrinterOutputDevice: Resending from: 12132 < [10:52:11] Error:Line Number is not Last Line Number+1, Last Line: 12131 < [10:52:11] USBPrinterOutputDevice: Resending from: 12132
I am running through a USB hub but I did see this issue yesterday with out the hub. I'm going to upgrade to Marlin 18.104.22.168 and try without the hub to confirm.
Same error, USB direct to workstation, no usb hub, with Marlin 22.214.171.124. Every line with Error:Line Number is not Last Line Number+1 is a pause in the print.
< [11:05:28] Error:Line Number is not Last Line Number+1, Last Line: 3436 < [11:05:28] USBPrinterOutputDevice: Resending from: 3437 < [11:05:28] Error:Line Number is not Last Line Number+1, Last Line: 3442 < [11:05:28] USBPrinterOutputDevice: Resending from: 3443 < [11:05:28] Error:Line Number is not Last Line Number+1, Last Line: 3442 < [11:05:28] USBPrinterOutputDevice: Resending from: 3443 < [11:05:28] Error:checksum mismatch, Last Line: 3446 < [11:05:28] USBPrinterOutputDevice: Resending from: 3447 < [11:05:28] Error:checksum mismatch, Last Line: 3458 < [11:05:28] USBPrinterOutputDevice: Resending from: 3459 < [11:05:28] Error:Line Number is not Last Line Number+1, Last Line: 3458 < [11:05:28] USBPrinterOutputDevice: Resending from: 3459
@brent.i: It looks like there are frequent communication errors, and Marlin is requesting resends. I would recommend replacing the USB cable. Unless this is happening across several workstations and printers, then it is not a software issue.
@brent.i: If it was working better before and now it is working worse, then that's good news. It means we just have to find out what changed and where. Tracking down the version where things went bonkers is a great start. If there is a Marlin/Cura combo that is good, and a Marlin/Cura combo that is bad; one useful test would be to try the Marlin from one combo with the Cura from the other, and that way decide whether it was a change in Cura or Marlin that makes the difference.
I have a print that has been running for 2-3 hours now with Cura LE 3.2.16 and Marlin 126.96.36.199. I only have one checksum mismatch and none of the Number+1 errors. So, no pausing with the older firmware. Appears to be a Marlin issue.
Update on this issue: @marcio found that if you turn on (check the box) Show debug messages in the Cura LE console, the pause issue goes away. If you turn debug messages back off, the pause issue immediately re-ermeges. FYI, the issue appears to be most easily repeatable with gcode for a model with a lot of texture and many short movements.
Note from @alexei in chat:
It's still thread unsafe I bet. Inserting logging would add some delays in sending to buffer, without which the buffer can be overfilled somewhere...
A further update to this.
I actually believe it is neither Cura nor Marlin at fault here. After further investigation, it appears as if the Rambo and Einsy boards (and all Arduino boards, in fact) have an Atmel 32u microprocessor that acts as a USB to serial converter. This chips is loaded up with some firmware for converting USB data into serial. It turns out that the firmware on this chip has a ring buffer size of 128 characters.
We further learned that Cura had no problems printing to Marlin 188.8.131.52, while it had problems printing to FW after 184.108.40.206. The only difference between the two firmware is that the Marlin BUFSIZE is 4 on the former, while it is 10 on the latter. This value is expressed in lines, and is the number of GCODE lines that Marlin can buffer at a time.
We also learned that Cura could print successfully if "Show debug messages" was enabled, but not when that was disabled.
Lastly, I also learned that the average GCODE line in Cura print is about 28 characters.
All these facts seem totally unrelated, but the key here is that four lines of GCODE (the Marlin default BUFSIZE) of about 28 characters each (the average length of a GCODE line in cura) equals to 112, which is just shy of the maximum buffer size (128) in the FW that is loaded on the Arduino/Rambo/Einsy USB-to-serial chip.
- If we increase the Marlin BUFSIZE beyond 4, Cura will attempt to send more lines at a time than 4, which will overflow the 128 byte buffer on the USB-to-serial chip, leading to errors.
- If we enable logging in Cura, the extra time spend generating the logs will give enough time for the serial buffer to empty out, so the print will work.
Alexei and I have discussed this and we think there are two solutions:
- We could add a slight delay to MarlinSerialProtocol when it attempts to fill the Marlin buffer. A small delay at each line written will keep the 128 byte buffer on the USB-to-serial chip from overflowing, even if BUFSIZE > 4
- We could set the BUFSIZE in Marlin to 4. This is the default and it works because it keeps the host software from ever sending more than 4 lines at a time.
Either one of these fixes will solve the problem, but implementing both will ensure that Cura works with any version of Marlin, while ensuring that our FW will likely work with any host software.
Here is the offending line which caps the buffer size at 128 in the Arduino USB-to-serial FW: