Octoprint: Communication Failure with Version 1.3.6

[cyberreefguru]

What were you doing?

Nothing. I started the print and came back to the error. Second time since upgrading octopi has failed to monitor print, but print continues on successfully.

Ideally provide exact steps to follow in order to reproduce your problem:

1. Load STL on to SD card
2. Pre-heat Printer
3. Click Print
4. Watch first few layers successfully go down.
5. Have Dinner
6. Come back
7. Notice failure
8. Submit defect report

What did you expect to happen?

I expected to see OctoPrint continuing to monitor the print.

What happened instead?

Unhandled communication error.

Did the same happen when running OctoPrint in safe mode?

I didn't try it, but I will. This is the second failure of 2 since upgrading (so 100% failure rate -- though the print continues until complete).

Version of OctoPrint

v1.3.6

Operating System running OctoPrint

OctoPi Version 0.13.0

Printer model & used firmware incl. version

Prusa i3 MK2 - 3.0.9

Browser and Version of Browser, Operating System running Browser

Mac OS 10.12.6 - Safari Version 11.0.2 (12604.4.7.1.4)

Link to octoprint.log

https://gist.github.com/cyberreefguru/5d76d262d053e559c820d03452a213f1

Link to contents of terminal tab or serial.log

Not currently enabled but I will.

Link to contents of Javascript console in the browser

https://gist.github.com/cyberreefguru/f9166ada02d95fd95c5ac982b3626253

[GitIssueBot]

Hi @cyberreefguru,

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 - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

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-01-01 02:10 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.

[JohnOCFII]

You've got a lot of plug-ins. Looking at the log, there are some plug-in related issues. I think the safe mode testing is a good idea -- and/or -- if there are plug-ins that you aren't using, I'd disable them.

[foosel]

No way to look into this with the contents of the terminal tab or even better a serial.log.

2017-12-17 23:48:57,485 - octoprint.util.comm - INFO - Ignoring resend request for line 1 == current line, we haven't sent that yet so the printer got N-1 twice from us, probably due to a timeout
2017-12-17 23:49:57,526 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2017-12-17 23:49:58,425 - octoprint.util.comm - INFO - Ignoring resend request for line 1 == current line, we haven't sent that yet so the printer got N-1 twice from us, probably due to a timeout
2017-12-17 23:50:58,466 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2017-12-17 23:51:28,497 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2017-12-17 23:51:58,529 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2017-12-17 23:52:28,562 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2017-12-17 23:52:58,594 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.

^- this from your octoprint.log however suggests some serious communication issues between OctoPrint and your printer. Make sure to read this FAQ entry. Since you are encountering this against a MK2, you might also want to enable Settings > Serial communication > Advanced options > Simulate an additional ok for resend requests since there appears to exist a bug in the Original Prusa firmware branch currently (also refer to #2285 and #2291).

Your steps to reproduce are also unclear. "Load STL on SD card" - I guess you mean a gcode file? Sounds like you were printing from SD card, but through OctoPrint? Please clarify and provide missing information.

[cyberreefguru]

Hello Gina - First, sorry for the incomplete details. Second, many thanks for the prompt reply. Yes, I am printing gcode from the SD card through Octoprint. Yes, there are serious communication issues - I can see that from the log. But I was not having any issues until the most recent release. I've been using Octoprint with my Prusa for over 2 years without a problem. I've been on the same version of the firmware for probably a year now. I've enabled serial logging and captured a total fail. Then I disabled plugins via safe mode and retested - it worked with the plugins disabled, but the log file is similar. Crazy communication issues but it recovered. I canceled the print and tried again - same result, issues but recovery. I'm interested if I should put M27 down as a long running command since that might be the problem during the calibration cycle?

serial.log.2017-12-18_22-51-40.txt
serial.log.txt

-Tom

[teddybee]

I have similar issue that I wrote to the Marlin's page. Until I don't print, it is good. When printing it drops the connection within half an hour(sometimes after few minutes). Error messsage:
"State: Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2025"
All plugins disabled, cable is good, short, shielded. I printed several times with this orangepi and cable. Only the board and Octoprint's version have changed since then.

[teddybee]

When the printer disconnects, I see this log in dmesg:
[ 541.260085] usb 6-1: reset full-speed USB device number 2 using sunxi-ohci
[ 541.477149] cdc_acm 6-1:1.0: ttyACM0: USB ACM device

Now these disconnects are very frequent and I got them when printer is idle as well. I have reverted Octoprint to 1.3.5.

[teddybee]

I have an update. I cut off the wifi chip from orangepi to free up some power, I reinstalled the linux with the newest kernel and OctoPrint. Measured the 5V lane, it was 4.99. Disconnections still happened.
I tried out with a PC and printing was good with 1.3.6.
Probably my OrangePi is sensitive to MKS Sbase boards, with Anet controller it was perfect.

[ir-fuel]

I don't know if it is related but I have something similar. I had it fail a couple of times on very long prints (24h print that failed after 18h). It just disconnects from the printer (Prusa i3 mk2 MMU), stops printing but the printer keeps on heating bed and nozzle.

This is what I saw in the log file:

2017-12-31 21:33:43,700 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port Traceback (most recent call last): File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.6-py2.7.egg/octoprint/util/comm.py", line 2025, in _readline ret = self._serial.readline() File "build/bdist.linux-armv7l/egg/serial/serialposix.py", line 475, in read raise SerialException('device reports readiness to read but returned no data (device disconnected or multiple access on port?)') SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?) 2017-12-31 21:33:43,703 - octoprint.util.comm - ERROR - Please see https://bit.ly/octoserial for possible reasons of this.

I currently don't trust Octoprint anymore for long prints. Will print directly from SD.

[tvi675]

This looks similar to my report #2363 that’s been an ongoing issue since upgrading to 1.3.6. As above, I’ve lost confidence for longer prints unless I’m doing them directly from the SD card.

[AJMOZ]

I too am having semi-random disconnects during modest jobs (<2hrs) using Octoprint 1.3.6 on Raspberry Pi zero W and CR-10 Marlin firmware. This has just begun in the past 2 weeks and prior to that 10+ hour prints ran with no problems.

The error message is as follows:

Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2025

I will disable recently added plugins, enable serial logging and retry. Please advise if this is a known new bug, or if any particular Octoprint plugin is buggy. This smells to me like something else on the PI is talking to the USB serial port about an hour after the print begins....

Thank you for the hard work on a very useful tool!

[foosel]

Just to make sure this doesn't get overlooked: https://github.com/foosel/OctoPrint/wiki/FAQ#octoprint-randomly-loses-connection-to-the-printer-with-a-serialexception

[akudaikon]

After suffering from this problem for months, I've spent a lot of time recently trying to track it down (Octoprint version, power supply, USB cable, etc). The cause is using a Raspberry Pi Zero W. A few months ago I swapped out a Raspberry Pi B+ for a Zero W and that's when the problems started. I just switched back to using the B+ and everything is back to normal.

EDIT: That fixed my "SerialException: device reports readiness..." issues, but now I'm having stalls with no errors. Printer still shows as connected and printing, temperatures still held, but no further communication in the Terminal.

[foosel]

I'm having the feeling this is becoming the general "I have a problem with my printer communication" thread.

We have this:

• @cyberreefguru runs a Prusa MK2 with firmware 3.0.9. Prints from SD. Has severe communication issues with loads of binary garbage sent by the firmware to OctoPrint and also the missing ok after resend bug present in Prusa's Marlin fork until version 3.1.1 (which AFAIK is currently only available for MK3). This bug plus communication issues is a bad combination. Communication issues make resend requests more likely, and those lacking the ok then means trouble. Try my earlier suggestions and also check all steps in the FAQ.
• @teddybee was observing actual full blown USB disconnects after switching to an OrangePi, printer model & firmware unknown. Nothing OctoPrint can do about that, if the OS loses your printer that's many layers beneath OctoPrint. And in fact the issues were fixed once switched back from the OrangePi as far as I understand. Printer model & firmware unknown.
• @ir-fuel is running into classic "SerialException" errors. Printer model & firmware unknown. Check all steps in the FAQ, OctoPrint can't do anything about unreliable comms on that level and yes, the most common reasons actually are brown outs, and cables used for powering stuff can become broken/increase resistance. I can't do anything about this situation, it's happening on a layer beneath OctoPrint.
• @AJMOZ is running against a CR-10 from a Zero W (that Pi model is not recommended btw). Yet another "SerialException" issue. See my reply to @ir-fuel.
• @akudaikon (unknown printer model & firmware....) first ran into the "SerialException" issue again, solved it after switching away from the (not recommended) Pi0W to a B+. Now running into something sounding like either the firmware stopping to respond, or some acknowledgement "ok" going amiss. In any case, sounds different than what we so far had here. Please open a new ticket with all information included that's requested in the ticket template.

In a nutshell, I can't really help any of you with anything else but the above suggestions.

The whole "SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)'" issue is well documented in the FAQ for a reason and triggered one layer beneath OctoPrint. If there was something wrong with the serial comms in OctoPrint 1.3.6 in general (which btw didn't really change since 1.3.5), I'm fairly sure I'd heard more about that by now and also run into it myself.

I know none of you will like this, but I'm closing this since it doesn't look like a bug in OctoPrint, this is a bug tracker and I have to keep things manageable here. Comments are still possible though. In any case, the mailing list might be better suited for these kinds of issues.

[AJMOZ]

Thanks for your efforts Gina on the entire project. Despite seeing the serial issues appear suddenly on RPi0W, with no explanation, switching to RPi3B seems to eliminate them. I suspect some change has happened in Octoprint, kernel or driver around the same time which causes the RPi0W to lose USB interrupts or DMA. This was without webcam. Could have been the Octoprint periodic online check, come to think of it.

Not an Octoprint issue but coming from a deeply embedded background - this sort of stuff just shouldn't happen in an OS. The linux realtime and driver infrastructure appears really broken.
Thank you Gina and all for your information.

[akudaikon]

@foosel Thanks Gina!

If it helps, the stalling issue I'm now seeing is definitely a Marlin firmware issue. I'm currently running Marlin 1.1.0-RC3 and just had it happen while trying to print via Simplify3D over USB connected to my computer. Definitely isn't an OctoPrint issue, which is a relief!

[AJMOZ]

I believe the recent Marlin firmwares are experiencing severe MIPS limitations on ATMEGA devices after the introduction of linear acceleration and they recommend downgrading or turning that feature off. It’s time for an ARM based standard board and escaping the clutches of that dreadful Arduino platform.

From: akudaikon [mailto:[email protected]]
Sent: Tuesday, 20 February 2018 1:03 PM
To: foosel/OctoPrint
Cc: AJMOZ; Mention
Subject: Re: [foosel/OctoPrint] Communication Failure with Version 1.3.6 (#2299)

@foosel https://github.com/foosel Thanks Gina!

If it helps, the stalling issue I'm now seeing is definitely a Marlin firmware issue. I'm currently running Marlin 1.1.0-RC3 and just had it happen while trying to print via Simplify3D over USB connected to my computer. Definitely isn't an OctoPrint issue, which is a relief!

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

[teddybee]

I have been finished now a 2 hours long print without an issue with Octoprint 1.3.6.
The hardware, cable, etc haven't changed. Only the armbian got an update on the orangepi(newer kernel as well) and newer Marlin 2.0.0b compiled to my Mks Sbase.
So far so good, its promising.

[AJMOZ]

With enormous respect, the 'it's somewhere else in Linux' argument is a cop-out. There may be actions Octopi can take to reinitialise a lower level issue such as restarting/reloading the USB serial driver etc.

I suspect the real culprit may be fragile Broadcom USB drivers on the Pi family, cloned FT232 chips on the printers or a combination of both, but the app takes all the consumer flak, as always. :-(
Best wishes

[foosel]

There may be actions Octopi can take

That might well be, but this is OctoPrint's bug tracker, not OctoPi's. From OctoPrint's perspective and also capability of influence as a platform agnostic userspace program, this is completely outside of its control, and will also stay this way. Also, it wouldn't even have the necessary rights to fumble around with drivers in its normal setup. And even if it could and would, I'm fairly sure it wouldn't be able to fix inherently unstable setups this way, but I'd be happy to be proven wrong.