Octoprint with SKR 1.3

What is the problem?

I purchased for my printer a BigTreeTech SKR 1.3 and have tried to connect with the Octoprint. The Octoprint is disconnecting after a while. It used to work very well with my Anet A8 board v1.5.

What did you already try to solve it?

I bought my Raspberry Pi 3 in Canada (currently in the UK) and received it with power supply from Canakit. I have read that power supply might cause the issue, so I bought an original power supply from Raspberry shop that did not resolve the issue. Also, added some codes for 32-bit boards lpc 1768. I can't find it now but it was on this forum.

Logs (octoprint.log, serial.log or output on terminal tab, ...)
octoprint (1).log (158.0 KB)
serial.log (740 Bytes)

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, ...)
Raspberry Pi 3 with original power supply.
Octoprint Version 1.3.11
Printer Anet A8 metal frame with BigTreeTech SKR 1.3 - TMC2208
Marlin 2.0

Edit: Serial log added

The serial.log would help alot.

1 Like

:grin:
Have you read you serial log :smiley: ?
It just says
2019-07-20 12:02:47,261 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log

Please enabled the serial logging and wait until the error occurs the next time :wink:

off topic: May I ask where you got your A8 metal frame from? I want to buy one in the near future but I'm not really sure which.

1 Like

@Dan, Do you know this url:

HTTPError: 401 Client Error: Unauthorized for url: http://stream.getanywhere.io/api/dev_settings

I'm wondering if Safe Mode might shed some light on this.

octoprint.log (24.5 KB) serial (1).log (8.6 KB)
Hi,

My applogise for such a delay for the response, here are requested files.

Edit, I have tried in safe mode, doesn't work

off topic: May I ask where you got your A8 metal frame from? I want to buy one in the near future but I'm not really sure which.

I have got it from one store in Poland, about 50 pounds all together :slight_smile:

Here's the end of the serial log, noting that M155 isn't a blocking sort of command:

2019-07-24 16:30:57,318 - Recv: FIRMWARE_NAME:Marlin bugfix-2.0.x (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:3D Printer EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
...
2019-07-24 16:30:59,490 - Send: M155 S5
2019-07-24 16:30:59,492 - Recv: ok
2019-07-24 16:32:29,581 - No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2019-07-24 16:32:29,624 - Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
2019-07-24 16:32:29,656 - Connection closed, closing down monitor

And here's the end of the octoprint log:

2019-07-24 16:23:58,579 - backoff - INFO - Backing off __get_dev_settings__(...) for 57.4s (HTTPError: 401 Client Error: Unauthorized for url: http://stream.getanywhere.io/api/dev_settings)
2019-07-24 16:24:18,405 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Detecting serial port"
2019-07-24 16:24:18,447 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial port" to "Opening serial port"
2019-07-24 16:24:18,452 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial port" to "Connecting"
2019-07-24 16:24:18,463 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2019-07-24 16:24:18,490 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Operational"
2019-07-24 16:24:18,501 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2019-07-24 16:24:18,628 - octoprint.plugins.ipOnConnect - INFO - ipOnConnectPlugin: 192.168.1.3
2019-07-24 16:24:18,636 - octoprint.util.comm - INFO - Printer reports firmware name "Marlin bugfix-2.0.x (Github)"
2019-07-24 16:24:18,668 - octoprint.plugins.ABL_Expert - INFO - self.printer_cap[eeprom] is now 1

2019-07-24 16:24:18,703 - octoprint.util.comm - INFO - Firmware states that it supports temperature autoreporting
2019-07-24 16:24:18,718 - octoprint.plugins.ABL_Expert - INFO - self.printer_cap[autolevel] is now 1

2019-07-24 16:24:18,735 - octoprint.plugins.ABL_Expert - INFO - self.printer_cap[z_probe] is now 1

2019-07-24 16:24:18,739 - octoprint.plugins.ABL_Expert - INFO - self.printer_cap[leveling_data] is now 1

2019-07-24 16:24:18,975 - octoprint.plugins.tracking - INFO - Sent tracking event printer_connected, payload: {u'printer_baudrate': 250000, u'printer_port': u'AUTO', 'firmware_name': 'Marlin bugfix-2.0.x (Github)'}
2019-07-24 16:24:20,925 - octoprint.plugins.ABL_Expert - INFO - Grid mesh size is 4
2019-07-24 16:24:56,308 - backoff - INFO - Backing off __get_dev_settings__(...) for 93.3s (HTTPError: 401 Client Error: Unauthorized for url: http://stream.getanywhere.io/api/dev_settings)
2019-07-24 16:26:09,485 - octoprint.util.comm - INFO - Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
2019-07-24 16:26:15,891 - octoprint.util.comm - INFO - Telling the printer to set the busy interval to our "communicationBusy" timeout - 1s = 2s
2019-07-24 16:26:29,972 - backoff - INFO - Backing off __get_dev_settings__(...) for 17.5s (HTTPError: 401 Client Error: Unauthorized for url: http://stream.getanywhere.io/api/dev_settings)
2019-07-24 16:26:47,866 - backoff - INFO - Backing off __get_dev_settings__(...) for 88.4s (HTTPError: 401 Client Error: Unauthorized for url: http://stream.getanywhere.io/api/dev_settings)
2019-07-24 16:27:23,353 - octoprint.util.comm - INFO - No response from printer after 3 consecutive communication timeouts, considering it dead.
2019-07-24 16:27:23,427 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
2019-07-24 16:27:24,087 - octoprint.plugins.tracking - INFO - Sent tracking event commerror_timeout, payload: {'commerror_text': 'Too many consecutive timeouts, printer still connected and alive?'}

Some of that "backoff" stuff suggests that there's an uphappy plugin, I'd guess. (Anywhere?)

It looks like OctoPrint tried to tell the firmware that it wants a 2-second timeout. This was followed by it not receiving any response within three attempts.

It may be worthwhile to visit OctoPrint's Settings -> Serial Connection -> Intervals & Timeouts screen. Hover over the second communication timeout field (which presumably is 3 seconds currently). Try adjusting this to something higher and see if it behaves. You'd think a 32-bit controller board would respond better, though.

1 Like

I did increased the timeouts, and happened the same, looks like the board doesn't want to send the temperature values to the octoprint.

Do you have any other suggestion?

I'm a bit confused by the parameter S5. According to this, M155 only takes S0 or S1 as parameter

http://marlinfw.org/docs/gcode/M155.html

There is a link, it stands for seconds as far as I understood.

I see, it seems they had changed this recently.
Have you tried - just for the try - M155 S1?

Maybe AUTO_REPORT_TEMPERATURES in Configuration_adv.h isn't enabled...

It is, I have checked it already :slight_smile:

1 Like

Well, if OctoPrint thinks that it told the firmware to report temperature periodically and the firmware doesn't, then this could cause the problem. I guess, look for the option to toggle this off. It would either be under the printer definition or under the Serial Communications part of Settings.

I cant find where I can switch temperature off or at least change the code.

Go to Settings -> Serial Connection -> Intervals & timeouts -> Query intervals and hover over the Temperature interval (autoreport) field.

1 Like

I have (what I think is) the same problem.
I have 2 printers. An FT5-R2 running Marlin 1.x and a homebuilt i3 that I just upgraded to an SKR 1.3 and so it is running Marlin 2. I have a second SKR 1.3 waiting to install in my FT5.
The Octoprint (RPi3b+) on the FT5 is working just fine. I see the following polling in the terminal:

Send: N2 M21*18
Recv: FIRMWARE_NAME:Marlin 1.1.3 (Github)
PROTOCOL_VERSION:1.0 MACHINE_TYPE:FT-5 Marlin 1.1.2 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: ok
Recv: echo:SD card ok
Send: M20
Recv: ok
Recv: Begin file list
Recv: End file list
Recv: ok
Send: M105
Recv: ok T:20.70 /0 B:20.70 /0 @:0 B@:0
Send: M105
Recv: ok T:20.98 /0 B:20.70 /0 @:0 B@:0
Send: M105
Recv: ok T:20.86 /0 B:20.94 /0 @:0 B@:0

BUT the newly upgraded printer shows a very different communication. It is not sending periodic M105 commands when things are idle. And eventually it will declare a communication fault. I have attached the serial logs from both Octoprint systems. They are labled Marlin1serial and Marlin2serial.

I just flashed both RPi devices and allowed the latest update to load. I think the two systems are on identical Octoprint versions. As far as I can tell, when Octoprint sees that it is Marlin 2, it doesn't poll the printer like it does when it is Marlin 1.

Marlin1serial.log (3.9 KB) Marlin2serial.log (6.4 KB)

Update -
Reminder - I have two RPis running Octoprint. Octoprint1 connects to a board running Marlin 1 while Octoprint2 connects to a board running Marlin2. Octoprint1 functions just fine while Octoprint2 faults with a communication error.
This morning I connected Octoprint1 to the printer running Marlin2 and it also faulted. Again I did not see the steady progression of M105 commands like when it is connected to printer 1. I put it back on printer 1 and communication resumed as normal.
There is clear behavior difference when connected to Marlin 2.x. It does not send the regular M105 commands in idle to keep communication running. This is either a bug in Octoprint or some sort of configuration issue.

I looked at the Marlin2 log...

Send a manual M105 to the printer via the terminal interface. If nothing comes back then something is wrong with your marlin. Then send M155 S5 to turn on the Automatic Reporting. OctoPrint is sending it Marlin 2.0 is not reponding after the initial ok. How many hotends do yo u have configured? Do you have the thermistors plugged in?

I have an SKR 1.3 with Marlin 2.0 bugfix as well.

I may have tracked this down a bit further and you are on the right track.
I think it is actually the M155 S4 command that is being ignored by my board.
It looks like when Octoprint connects and sees that it is Marlin 2, it sends an M155 Sx command to have the controller report status every x seconds. It looks like my board is ignoring that command (even though it replies with OK).
A little more Google digging over the weekend and it may be this is a bug with the Big Tree Tech version of Marlin 2, and the recommendation is to load Marlin 2 from the official Marlin GitHub. The two versions are quite different and my first upload attempt has made it so the board will no longer connect. I may have missed a driver or setting.
It looks as though Octoprint is just fine and my implementation of Marlin 2 is off.

Did you change the serial ports in configuration.h?

Line 107: #define SERIAL_PORT -1
Line 116: #define SERIAL_PORT_2 0

You can leave 107 alone and just uncomment 116. The youtube tutorials I went from changed them to what I put here.