Com failure SKR PRO Octoprint

Get Help
1

What is the problem?
Two issues:

  1. xy micropauses while e continues extruding at each print (com error pops up)
  2. randomly does a abl probing at the same point
    What did you already try to solve it?
    I have tried increasing intervals and timeouts, maximizing marlin buffer size, changing usb cables, changing power supplies
    Logs (octoprint.log, serial.log or output on terminal tab, browser error console ...)
    Communication Error
    Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ...)

Octoprint 1.3.1
Raspberry 3b+
Any browser
Win10
SKR PRO - Marlin 2.0
Self built corexy

2

Imagine visiting a doctor to diagnose some ailment only to discover that she's blind. She'll probably want more information from you (noting that the default Get Help template asked for logs which you didn't provide). And sometimes a picture is worth a thousand words: a photo of a blobby printed part might be useful.

By "micropause" do you mean stopping-for-a-second-in-place? If so, this has been called a variety of things in the past:

  • blobbing
  • shredding
  • stuttering

This has been discussed often in 3D printer forums and for almost every software available. It's most often associated with delta-style printers since the last-minute mathematical coordinate conversions are too much work for the little 8-bit Arduino processors usually employed. Similarly, the limited RAM on the 8-bit boards can also contribute to this as well as a too-small default receive buffer on the Marlin firmware side of things.

3

You are right, i will post a log of my last long print which contained fewer blobs upon following some insight on your linked post. Expect it by tomorrow evening as it will be done by that time. In the meanwhile i post what i am up to, they are blobs followed by heavy underextrusion. Pay attention that it is not the z seam as i have aligned it and can clearly see it.

photo5839171162226143553
photo5839171162226143553.jpg720×1280 75 KB

1 Like
4

Ok so i had to interrupt last long run print. here is a test I did today (had to cut in half the code to upload it here), from the serial.log I notice some com drop outs but I doubt it might be a usb issue (tried several cables, included ferrite). Apart from that I dont see anything crucial, am I blind?

serial (2).log (2.8 MB)

photo5859669860013945367
photo5859669860013945367.jpg960×1280 59.2 KB

5

Test Supporti.gcode (1.6 MB)

6

You can probably rule out the 32-bit processor as being a bottleneck (over the standard 8-bit board).

I see a number of "echo:busy: processing" in the serial log, specifically 134 instances. If this were a smaller part, I'd suggest counting the number of blobs on the surface and comparing them with this number.

You've got at least one of these:

2019-10-18 16:30:48,923 - Changing monitoring state from "Printing" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2739)"
2019-10-18 16:30:48,933 - Connection closed, closing down monitor

I see stuff like this which isn't pretty. Note that the second line includes two sets of temperature report but it's missing the EOL marker perhaps after the first one. Actually, it looks like the "@:0 B@:0" part was also truncated on the inbound trip.

2019-10-18 16:31:54,057 - Recv:  T:20.62 /0.00 B:21.41 /0.00 @:0 B@:0
2019-10-18 16:31:58,057 - Recv:  T:20.47 /0.00 B:21.09 /0.00 T:20.47 /0.00 B:21.09 /0.00 @:0 B@:0

You've got this so you might consider removing the SD card from the printer board.

2019-10-18 17:47:49,521 - Recv: echo:SD init fail

You've got this on a G34 so you should tell OctoPrint it's a long-running command. Likewise, you get a repeat performance of this on the G29 which then follows.

2019-10-18 17:48:13,648 - Send: N6 G34*24
...
2019-10-18 17:48:27,325 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

This one is quite possibly blob-worthy in that you're moving/extruding, there are several temperature events logged in the meantime and then OctoPrint is saying that the printer hasn't answered yet.

2019-10-18 17:54:55,228 - Send: N27 G1 X128.621 Y130.273 Z0.2 E0 F6000*117
2019-10-18 17:54:56,044 - Recv:  T:204.96 /205.00 B:59.32 /60.00 @:52 B@:38
2019-10-18 17:54:58,044 - Recv:  T:204.91 /205.00 B:59.28 /60.00 @:52 B@:41
2019-10-18 17:55:00,044 - Recv:  T:204.29 /205.00 B:59.30 /60.00 @:61 B@:41
2019-10-18 17:55:00,191 - Recv: echo:busy: processing
2019-10-18 17:55:02,044 - Recv:  T:204.20 /205.00 B:59.31 /60.00 @:62 B@:41
2019-10-18 17:55:04,044 - Recv:  T:203.71 /205.00 B:59.38 /60.00 @:69 B@:39
2019-10-18 17:55:05,190 - Recv: echo:busy: processing
2019-10-18 17:55:06,044 - Recv:  T:203.57 /205.00 B:59.36 /60.00 @:71 B@:42
2019-10-18 17:55:08,044 - Recv:  T:203.93 /205.00 B:59.35 /60.00 @:64 B@:44
2019-10-18 17:55:10,044 - Recv:  T:204.29 /205.00 B:59.60 /60.00 @:60 B@:34
2019-10-18 17:55:10,190 - Recv: echo:busy: processing
2019-10-18 17:55:12,044 - Recv:  T:204.33 /205.00 B:59.71 /60.00 @:61 B@:34
2019-10-18 17:55:14,044 - Recv:  T:205.00 /205.00 B:59.78 /60.00 @:52 B@:34
2019-10-18 17:55:15,190 - Recv: echo:busy: processing
2019-10-18 17:55:16,044 - Recv:  T:205.00 /205.00 B:59.77 /60.00 @:55 B@:37
2019-10-18 17:55:18,044 - Recv:  T:205.00 /205.00 B:59.70 /60.00 @:56 B@:41
2019-10-18 17:55:20,044 - Recv:  T:204.87 /205.00 B:59.73 /60.00 @:59 B@:40
2019-10-18 17:55:20,190 - Recv: echo:busy: processing
2019-10-18 17:55:22,044 - Recv:  T:204.96 /205.00 B:59.70 /60.00 @:58 B@:42
2019-10-18 17:55:24,044 - Recv:  T:204.78 /205.00 B:59.73 /60.00 @:61 B@:42
2019-10-18 17:55:25,190 - Recv: echo:busy: processing
2019-10-18 17:55:26,045 - Recv:  T:204.82 /205.00 B:59.74 /60.00 @:60 B@:42
2019-10-18 17:55:28,044 - Recv:  T:204.87 /205.00 B:59.70 /60.00 @:59 B@:44
2019-10-18 17:55:30,190 - Recv:  T:204.78 /205.00 B:59.91 /60.00echo:busy: processing
2019-10-18 17:55:32,043 - Recv:  T:204.91 /205.00 B:60.09 /60.00 @:58 B@:31
2019-10-18 17:55:32,046 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
7

I see, thank a lot for your input! i did what you adviced about the long commands and seems to be gone now. I did several test and i think i solved it by enabling "no timeouts" in marlin, increasing tx buffer and decrease by a lot the rx buffer. Now i dont get anymore a communication error which i had before on several times. On the other side, instead of a busy echo i get a wait recv message from time to time. I will test it further!

1 Like
8

If you see any more of the weird/truncated received lines from your firmware then treat this as a serial cable problem. (You need internal metallic shielding or a ferrite core on that.)

Let us know (photo) how the blobbing goes after the updates you did.

9

Hi, apologies if I am coming back to this so late. I could print flawlessly for some hours straight without incurring in the above mentioned issue, however I had still very few blobs and from time to time skr pro would stop communicate with octoprint. This until yesterday when I upgraded to different drivers and official marlin 2.0. It works perfectly at any speeds without a single com issue. Thank you again for your support!