Octoprint: Repeated Communication error with Prusa Mk3 Firmware: 3.4.1-1356

[asterixorobelix]

What were you doing?

I simply connect to printer via octoprint.local and after about 2 minutes receive a: Communication error

Steps to reproduce:

1. login to octoprint.local with credentials
2. Select --> Serial Port: Auto, Baudrate: Auto, Save Connection Settings: Tick, Auto-connect on server startup: Tick
3. Click connect
4. Octoprint connects to printer successfully
5. After about 2 minutes, Octoprint disconnects and displays red Communication Error - State: Offline (Error: Too many consecutive timeouts, printer still connected and alive?)
6. Terminal Output: Attached below
7. Same occurs if these steps are repeated.
8. Same occurs when usb cable to Raspberry pi is swapped out for another one
9. I have also tried swapping out RPIs and disconnecting my webcam. Issue still occurs

What did you expect to happen?

I expected that Octoprint would be able to maintain connection with printer

What happened instead?

Octoprint lost connection with printer

Did the same happen when running OctoPrint in safe mode?

Yes

Version of OctoPrint

Version 1.3.9

Operating System running OctoPrint

Version 0.15.1 running on a Raspberry Pi 3 Model B V1.2
I am also using the official Raspberry Pi power supply. Red power light is on and steady.
Raspberry pi is connected to the internet via ethernet cable, not wifi
RPI is connected with ferrite bead cable.

Printer model & used firmware incl. version

Prusa Mk3, Firmware: 3.4.1-1356, running on Einsy Rambo 1.1a board

Browser and version of browser, operating system running browser

Google Chrome, Version 69.0.3497.100 (Official Build) (64-bit) Windows 10 Pro, version 1803
The same behaviour occurs on Firefox Quantum, Version 62.0.2 (64 bit) Windows 10 Pro, version 1803
Note - I have also tested with a macbook air running macOS High Sierra, Version 10.13.3: Safari version 11.0.3 (13604.5.6)

Link to octoprint.log

https://pastebin.com/fmjdbwrR

Link to contents of terminal tab or serial.log

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=0x6f9b0fb0, 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
Recv: start
Send: N0 M110 N0*125
Changing monitoring state from "Detecting baudrate" to "Operational"
Send: N1 M105*38
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N0 M110 N0*125
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N1 M115*39
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.
Changing monitoring state from "Operational" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
Connection closed, closing down monitor

Link to contents of Javascript console in the browser

Screenshot(s)/video(s) showing the problem:

I have read the FAQ.

edit by @foosel: fixed formatting

[GitIssueBot]

Hi @asterixorobelix,

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-10-24 21:20 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.

[bolsoncerrado]

I think Prusa is aware of this bug on 3.4.1 - you should flash back to a previous firm version.

[asterixorobelix]

Hi bolsoncerrado

According to the Prusa Changelog (
https://www.prusa3d.com/drivers/firmware-changelog/#mk3), firmware version
3.4.1 should have fixed Octoprint communication issues from their side.

However, I will try downgrading the firmware.

Regards,
Nathan Stasin

On Thu, 11 Oct 2018 at 12:55, bolsoncerrado [e-mail]
wrote:

I think Prusa is aware of this bug on 3.4.1 - you should flash back to a
previous firm version.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/2843#issuecomment-428911467,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATlKU1kJz-G7Cnpgh3NNlSpssm_1TTRlks5ujyOrgaJpZM4XWJOe
.

[bolsoncerrado]

I dont think thats the issue they fixed....I think they introduced a new one actually. At least I run all my Prusas with Pi's and never had a communications issue before, until upgrading to 3.4.1....

[asterixorobelix]

OK, thanks. I will definitely downgrade the firmware then.
Whats the highest firmware version which you have found plays nicely with
octoprint? Did 3.3.1 work for you?

On Thu, 11 Oct 2018, 13:45 bolsoncerrado [e-mail] wrote:

I dont think thats the issue they fixed....I think they introduced a new
one actually. At least I run all my Prusas with Pi's and never had a
communications issue before, until upgrading to 3.4.1....

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/2843#issuecomment-428924687,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATlKU9x8AZzVNo7jYzqV7CYlYYCP2RdSks5ujy9PgaJpZM4XWJOe
.

[bolsoncerrado]

3.4.0 works nice on my Mk3
3.3.1 on my Mk2.5

[asterixorobelix]

@bolsoncerrado I have downgraded the firmware all the way to 3.1.1 and the problem still occurs

[asterixorobelix]

Updated Octoprint log file, with downgraded firmware versions:
https://pastebin.com/q50tYUFt

I will see if getting the Prusa people involved adds any insight

[asterixorobelix]

I will add that I also cant connect to the printer via Pronterface on the mac

[asterixorobelix]

I have contacted Prusa Technical support who say that they will look into it

[foosel]

I will add that I also cant connect to the printer via Pronterface on the mac

If Pronterface also doesn't connect, that definitely sounds like a firmware issue. And looking at the log it shows that the printer simply doesn't respond to OctoPrint's desperate pleas for starting up a dialogue:

Send: N0 M110 N0*125
Changing monitoring state from "Detecting baudrate" to "Operational"
Send: N1 M105*38
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N0 M110 N0*125
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N1 M115*39

It should have responded with an ok to any of those commands. But it didn't respond at all.

So - nothing that can be fixed in OctoPrint, needs to be fixed in the firmware. Might be that it hangs on bootup, I've seen this happen occasionally.

[suprechent]

I had your exact issue. I just fix mine by turning "RPi" off in settings and everything works as its suppose too. Hope this helps

[aderusha]

I had installed an RPi zero W into my new Mk3 but the performance was horrible so I switched back to an RPi3B+ and was seeing this issue. @suprechent pointed out the source of my problem - I still had the rpi port enabled on the printer. Disabling that from the printer's LCD panel results in everything working like I expect. Thanks!

[davidmorabito]

I had installed an RPi zero W into my new Mk3 but the performance was horrible so I switched back to an RPi3B+ and was seeing this issue. @suprechent pointed out the source of my problem - I still had the rpi port enabled on the printer. Disabling that from the printer's LCD panel results in everything working like I expect. Thanks!

Hi @aderusha could you please explain how did you achieve that? Is a firmware configuration or Octoprint? Cannot find anything related to "rpi" in either Marlin code or OctoPrint settings.

Thanks a lot!

PS: I'm using Marling 1.1.9 and Octoprint 1.3.10

[aderusha]

I had installed an RPi zero W into my new Mk3 but the performance was horrible so I switched back to an RPi3B+ and was seeing this issue. @suprechent pointed out the source of my problem - I still had the rpi port enabled on the printer. Disabling that from the printer's LCD panel results in everything working like I expect. Thanks!

Hi @aderusha could you please explain how did you achieve that? Is a firmware configuration or Octoprint? Cannot find anything related to "rpi" in either Marlin code or OctoPrint settings.

Thanks a lot!

PS: I'm using Marling 1.1.9 and Octoprint 1.3.10

I'm using the Prusa fork of Marlin so I'm not sure where it lives outside of Prusa's firmware. For Prusa, it's under Settings > RPi Port