Page MenuHomeAleph Objects Inc

Pausing via USB Printing
Closed, ResolvedPublic


We have had a couple of reports of short pausing mid-print via T1814. Requesting attempts to duplicate and logs

Event Timeline

karrad created this task.Apr 10 2018, 10:38 AM
karrad created this object with edit policy "Cura LulzBot Edition (Project)".
Steven added a subscriber: Steven.EditedApr 10 2018, 10:55 AM

Running Marlin 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 and try without the hub to confirm.

Steven added a comment.EditedApr 10 2018, 11:08 AM

Same error, USB direct to workstation, no usb hub, with Marlin 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
karrad triaged this task as Normal priority.
karrad added a subscriber: marcio.

@marcio Hoping we can get your eyes on this one as well

karrad assigned this task to marcio.Apr 11 2018, 8:24 AM

@marcio iirc, you did some work on the USB communication with marlin. Can you take a look at this?

@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.

@marcio We have had this reported across at least 5 different printers and computers through beta testing: T1814

Can I have one of the affected printers? Unless I can reproduce this consistently, there is nothing I can do to troubleshoot this.

@marcio We are going to try to nail down the version where it broke. @Steven Just went back to 3.2.11 with included FW and there is no issue with same model and hardware set up

@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.

@karrad: I meant @karrad rather than @brent.i :)

@marcio And all that hard work I put into anonymity =P

marcio added a comment.EditedApr 11 2018, 9:23 AM

@karrad: Sorry, blew your cover (if your smiling face in your avatar hadn't blown it already).

I have a print that has been running for 2-3 hours now with Cura LE 3.2.16 and Marlin 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.

@Steven: There was a change introduced between Marlin and that I suspect may have caused this issue. Do you mind repeating the test using Marlin and Marlin to see if that is indeed the case?

Steven added a subscriber: alexei.Apr 12 2018, 11:14 AM

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, while it had problems printing to FW after 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.

MikeR added a subscriber: MikeR.Apr 12 2018, 3:59 PM

@Steven @marcio I have not been able to duplicate this with and c.17 and newer. Any objections to closing out for the c.18 smoke and beta test?

@karrad: Sounds good to me.

karrad closed this task as Resolved.Apr 17 2018, 8:26 AM