Prusa i3 Mk2.5 bed leveling leads to disconnect on firmware 3.3.0

[chatrat12]

I updated my Prusa i3 Mk2.5's firmware from 3.2.1 to 3.3.0 and now whenever I run the G28 command the printer disconnects. Not sure what is causing the incompatibility.

I did some testing. At first I thought it was an issue with the firmware, it still could be. However, I hooked my printer up to my computer and used Pronterface to send the G28 command and there are no issues, Pronterface remains connected after bed leveling. The printer or OctoPrint seems to stop communicating as soon as bed leveling is complete.

I did see another ticket related to bed leveling on the Mk3, but they specified it only happens on a failed level. None of my G28s are failing. I'm sure they are related.

What were you doing?

Sending G28 to the printer via the GCode Terminal

What did you expect to happen?

Nothing exciting :D

What happened instead?

The connection to the printer times out.

Did the same happen when running OctoPrint in safe mode?

Yes

Version of OctoPrint

Version 1.3.8

Operating System running OctoPrint

OctoPi 0.15.1

Printer model & used firmware incl. version

Prusa i3 Mk2.5 3.3.0

Browser and version of browser, operating system running browser

Chrome 64-bit 67.0.3396.99
Windows 10

Link to octoprint.log

OctoPrint Log

Link to contents of terminal tab or serial.log

Here is the full terminal for the 3.3.0 firmware G28 command

Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyACM0']
Connecting to: /dev/ttyACM0
Changing monitoring state from "Detecting serial port" to "Opening serial port"
Connected to: Serial<id=0x6e9d1130, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Send: N0 M110 N0*125
Recv: start
Changing monitoring state from "Detecting baudrate" to "Operational"
Recv: echo: 3.3.0-830
Send: N0 M110 N0*125
Recv: echo: Last Updated: Jul  2 2018 17:08:28 | Author: (none, default config)
Recv: Compiled: Jul  2 2018
Recv: echo: Free Memory: 2141  PlannerBufferBytes: 1392
Recv: echo:Hardcoded Default Settings Loaded
Recv: adc_init
Recv: PAT9125_init:0
Recv: FSensor
Recv: DISABLED
Recv: 
Recv: echo:SD card ok
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Prusa-Firmware 3.3.0 based on Marlin FIRMWARE_URL:https://github.com/prusa3d/Prusa-Firmware PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa i3 MK2.5 EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok
Send: M21
Recv: echo:SD card ok
Recv: ok
Send: M20
Recv: Begin file list
Recv: PLA_CA~1.GCO 36904102
Recv: PLA_GE~1.GCO 25124635
Recv: PLA_PR~1.GCO 292205
Recv: PLA_TR~1.GCO 11917070
Recv: PLA_TR~2.GCO 19192694
Recv: PLA_VA~1.GCO 7709051
Recv: PLA_WH~1.GCO 879725
Recv: V2CALI~1.GCO 785
Recv: PLA_AD~1.GCO 20381063
Recv: PLA_BA~1.GCO 259965
Recv: PLA_BE~1.GCO 3087232
Recv: PLA_BE~2.GCO 1374826
Recv: PLA_BU~1.GCO 7653936
Recv: End file list
Recv: ok
Send: M105
Recv: ok T:28.8 /0.0 B:28.2 /0.0 T0:28.8 /0.0 @:0 B@:0 P:28.2
Send: M105
Recv: ok T:28.9 /0.0 B:28.3 /0.0 T0:28.9 /0.0 @:0 B@:0 P:28.2
Send: G28
Recv: echo:busy: processing
Printer seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly
Recv: echo:busy: processing
Recv: echo:Enqueing to the front: "G80"
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
Connection closed, closing down monitor

Here is a truncated terminal for the working 3.2.1 firmware.

Send: M105
Recv: ok T:28.2 /0.0 B:27.9 /0.0 T0:28.2 /0.0 @:0 B@:0 P:27.8
Send: G28
Recv: echo:busy: processing
Printer seems to support the busy protocol, adjusting timeouts and setting busy interval accordingly
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: ok
Send: M113 S2
Recv: ok
Send: M105
Recv: ok T:28.1 /0.0 B:28.0 /0.0 T0:28.1 /0.0 @:0 B@:0 P:28.0

Link to contents of Javascript console in the browser

Starting dependency resolution...
packed_core.js?ccbe5583:14310 ... dependency resolution done
packed_core.js?ccbe5583:14613 Initial application setup done, connecting to server...
packed_core.js?ccbe5583:12559 Connected to the server
packed_core.js?ccbe5583:14591 Finalizing application startup
packed_core.js?ccbe5583:14475 Going to bind 32 view models...
packed_core.js?ccbe5583:14528 Did not bind view model CuraViewModel to target #wizard_plugin_cura since it does not exist
packed_core.js?ccbe5583:14528 Did not bind view model SoftwareUpdateViewModel to target #wizard_plugin_softwareupdate since it does not exist
packed_core.js?ccbe5583:2300 User chatrat12 logged in
packed_core.js?ccbe5583:14567 ... binding done
packed_core.js?ccbe5583:14587 Application startup complete

[GitIssueBot]

Hi @chatrat12,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - that can be found at discourse.octoprint.org. Go there for any kind of issues with network connectivity, webcam functionality, printer detection or any other kind of such support requests or general questions.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2018-07-21 03:50 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[chatrat12]

Apparently removing the screenshot section from the template has upset the bot xD

Just upgraded OctoPi to 1.3.9rc2, and the issue is no longer present which is interesting.

[chatrat12]

Had a print stop last night with the 1.3.9rc2 and 3.3.0 combo. It just stopped printing. The extruder and bed stayed at temperature and the motors were no longer engaged. OctoPrint status said it was printing. Clicking pause or cancel did nothing. I tried doing fake acknowledgement in the terminal nothing happened. Everything was completely unresponsive. I really can't tell if this is an OctoPrint problem or a printer firmware problem. Feels like serial communication may be bugging in the 3.3.0 firmware.

I did go through the logs and didn't see anything out of the ordinary. I forgot to copy them :( I was in a hurry to get my print done so I put OctoPrint back to stable and my printers firmware back to 3.2.1. I can do some more testing later to try and track down the ghost in the machine.

[kchristensen]

Seeing this too on an MK3 running 3.3.0. Downgrading to 3.2.0, and the issue stops, and I can print just fine.

[foosel]

Downgrading to 3.2.0, and the issue stops, and I can print just fine.

Which means that 3.3.0 changed something in how it handles things which causes issues with OctoPrint (and possibly other hosts), so I guess this should rather be reported in the firmware's bug tracker.

[foosel]

Closing this since it's now acknowledged on Prusa Research's side as a bug on their end. Comments are still open though.

[kazibole]

FYI supposedly resolved in Prusa firmware 3.3.1 - https://github.com/prusa3d/Prusa-Firmware/releases/tag/v3.3.1

[chatrat12]

Just flashed my printer to 3.3.1, can confirm the issue is resolved :)