Octoprint: Octoprint randomly disconnects from printer

[foulowl]

What were you doing?

Printer was printing an object, or printer was idling for roughly 20-30 min.

What did you expect to happen?

Printer should not disconnect from arduino.

What happened instead?

Printer disconnects randomly with the following error message:

Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1618
Changing monitoring state from 'Operational' to 'Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1618'
Connection closed, closing down monitor

printer freezes when disconnect happens, leaving the bed and nozzle hot. This is potentially dangerous.

Printer does not disconnect randomly when pronterface is used for communication.

Another item to note: connecting to the printer takes 20-30 seconds, whereas it takes less than a second with pronterface.

Branch & Commit or Version of OctoPrint

1.2.17

Printer model & used firmware incl. version

Prusa i3 and Marlin v1xxx

Browser and Version of Browser, Operating System running Browser

N/A

Link to octoprint.log

https://gist.github.com/foulowl/a90f3f531f94d5177fa358ad3c7567c4

Link to contents of terminal tab or serial.log

serial.log is empty. Full contents of terminal:
Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1618
Changing monitoring state from 'Operational' to 'Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1618'
Connection closed, closing down monitor

Link to contents of Javascript console in the browser

N/A

Screenshot(s) showing the problem:

N/A

I have read the FAQ.

Thanks!!

[foosel]

Quoting this comment on another issue with the exact same error message:

Something is up there with your printer connection, causing it to run out of synch on a level below OctoPrint. There's nothing OctoPrint can do about that sadly.

In the past users ran into this when attempting to access the serial port of the printer from another program at the same time as OctoPrint, but I guess this is not the case here. You could check if another USB cable makes a difference here, maybe even a different (stronger) power supply on the pi (in case it is caused by some weird brown out issue), but sadly that is about all I can recommend right now.

In any case, this is not a bug in OctoPrint. OctoPrint relies on the serial communication between it and the printer working on the transport level, which for whatever reason appears to not be the case here.

Also:

Another item to note: connecting to the printer takes 20-30 seconds, whereas it takes less than a second with pronterface.

Yes, but same as above applies. When the serial connection breaks down underneath OctoPrint, how can it send stuff like "shut down heaters" to the printer? It's not connected anymore. Sadly all firmwares that I know of do not have any safety features like "shut down heaters if nothing is received on a once active serial after n seconds*.

[foulowl]

I tried using pronterface instead of Octoprint, and encountered no such issue. ie, pronterface stays connected to the printer for several days with no disconnects. No failure condition was ever encountered with pronterface, and I disconnected manually after a few days. Octoprint disconnects once every 30-60 min.

That tells me the issue is with Octoprint, and not with the firmware.

Thanks!

[foosel]

Did you run pronterface on the same machine you ran OctoPrint on? Did you use the exact same cables and cable locations?

[foulowl]

Yes, everything was the exact same except I just used pronterface instead of octoprint.

Thank you!!

[skorokithakis]

I have the same problem, many of my prints have been ruined and I switched to SD card. I would prefer it if OctoPrint could work, but it's caused too many of my prints to fail for me to keep using it... Can it not just reopen the connection and resume?

[foosel]

No, it can't. Again - if the underlying transport layer (read: your serial connection) breaks away from underneath OctoPrint's feet, it can't handle that, it can't prevent that, it can't recover from that. You'll get the same behaviour if you disconnect the USB cable while a print is active, for OctoPrint it's exactly the same. So it cannot just reopen the connection and continue - there might be a valid reason why stuff broke, and simply going "eh" and trying to continue is a great way to break stuff or covering up actual connectivity issues.

I don't really have any options here apart from suggesting to look into cabling + power source.
All past cases where this error was reported to me, it turned out to be either a wonky USB cable (that constantly produced disconnects) or a bad power source for the Pi (which is notoriously difficult when it comes to stable power). Once that was swapped, the issues miraculously vanished.

And I can also look into updating the underlying serial transport library in a future version, in case it is a rare issue with that, but this is nothing I can do quickly because there might be compatibility issues with other printers with that, so it needs a lot of testing first.

But I can't do anything within OctoPrint to recover from this, or to handle it. If the connection between OctoPrint and the printer is unreliable, OctoPrint simply can't work. And no host can really.

If it runs reliably on the same hardware with the exact same cabling, PSU, CPU etc with something like Printrun, it might be that this simply causes a lower load on the system and hence doesn't trigger a potential brownout issue as reliably. From the basic implementation however, Printrun does nothing different than OctoPrint here (and yes, I read the source code) - it opens a serial connection via pyserial and then talks to the printer via that.

tldr: It doesn't break in OctoPrint, it breaks a layer beneath it. In the past that was always cured for people by swapping their USB cable and making sure their Pi's power source was a solid one (just because it says 5V/2A doesn't mean it really does deliver that). I can update pyserial in the future, but this not guaranteed to do anything here if it is a hardware/brownout issue, and that's highly likely.

[foosel]

Just remembered: What you could check though is - when it happens - what dmesg outputs (via SSH). Might give some hints as to what's going on with the serial device on the OS level.

edit: typo

[skorokithakis]

Sounds reasonable... Almost every issue with the Pi is a power issue. I'm half-tempted to make a simple wifi to serial adapter board and use that with Octoprint (running on my local computer or wherever) instead.

[foulowl]

I've tried different USB cables but doesn't seem to make a difference. Let me try a different power supply! Thanks!

[skorokithakis]

@foulowl, what's your baud rate?

[skorokithakis]

I changed the baud rate, thinking that might be it, no dice. I have a power supply from a tablet, changed both cables, nothing works, every print gets disconnected. The only thing that works is printing from the SD card.

[foosel]

What you could check though is - when it happens - what dmesg outputs (via SSH).

[skorokithakis]

Ah, yes, sorry, I forgot to do that. I will try it if I ever try OctoPrint again, but every single one of my prints failed, and I've changed every single piece of hardware (even Pi and SD card) and nothing worked.

[ntoff]

and making sure their Pi's power source was a solid one (just because it says 5V/2A doesn't mean it really does deliver that).

Just to add on to this, I have a bunch of phone chargers and tablet chargers (I'm not a hoarder, they do come in handy!) and while they do give you "5 volts", that's their unloaded voltage and when stressed with the current draw of a raspberry pi the voltage can actually drop below 5 volts, when you also factor in the power loss through the cables (you can search youtube for that subject if you wish) the voltage the raspberry pi sees might be 4.5 volts or even less, especially if it happens to be a raspberry pi 3. Phone chargers are fine for phones because a phone isn't going to care if it doesn't get the full 5 volts, a raspberry pi will care though.

Also on that error

'device reports readiness to read but returned no data

I get the same error when my printer's main power is turned off, could this actually be a printer power issue rather than an issue with the raspberry pi / octoprint? Maybe the onboard serial chip on the printer control board is a tad flaky? (not me, my printer is off, that's why I see it, I mean the other people who get it).

[skorokithakis]

@ntoff Hmm, thanks for the info, I have a bench power supply I can use, just to try it out, I guess. I'll also get the official Pi PSU, I've had loads of problems with RasPi power...

[skorokithakis]

I upgraded to 1.2.18 and used my desktop PSU with a shielded USB cable and no disconnects yet. It looks like it was, indeed, a power issue. I've ordered a genuine RasPi 3 PSU and will report results with that.

[shacal]

80% on USB / connections issues in pi -> power - Use quality, not cheap ebay powers
And yes, no automatic connection and continue.... that will break many other things 🗡

[ntoff]

@foulowl

Another item to note: connecting to the printer takes 20-30 seconds, whereas it takes less than a second with pronterface.

Do you leave octoprint on auto for the port and baud rate? If so, manually select the port and correct baud rate, the auto select will pretty much just run through a list of stuff to try until one works. Pronterface just connects to the port at the baud you specify so is much faster. Octoprint connects instantly for me when set to manual port/baud settings.

[skorokithakis]

My problems completely went away when I got the official Pi power supply. Print rate went to 100% from 0%, and I've made many prints since.

[foosel]

@skorokithakis thanks for getting back to us on this, and for the good news!

[skorokithakis]

No problem! As far as I'm concerned, any accidental disconnections are 99% the power supply's fault, and you can point people with the same issue to this thead so my tale can be an example to them!

[foosel]

Hehe, will do ;)

[foosel]

Considering this solved with proper power supplies since I heard nothing to the contrary.

[foulowl]

I have been testing this continuously since I have opened this issue.

Sadly, I must request it be reopened.

My baud rate is set to auto in octoprint, but I've tried the baud rate in the firmware also (115200)

I have tried a different usb cable, a different power supply (official RPi PSU) a different usb hub (official RPi HUB) and a different pi itself.

I have swapped these items out one at a time. Issue still occurs with each.

Issue does not occur in any configuration if I replace octoprint with pronterface. Pronterface immediately connects to my printer with no issues.

Octoprint, when attempting to connect, takes 2-4 minutes, and prints:
"�fx~����~�����xfx�����������~f��fx�������~��f�������fx����x��������~�f�������ff���ff�xffx��f~f���������f��f��������x�x�f��x�f��~�������f�������ff���ff������fx��f��f~��������������x���f��������x�����x���f��f�����������fx��f��f~���������f������fx��f��f~��������f��fx��f��~������fx��f��f~��������f��������x����f�f�������xxf��f�~��f����f���~��f�f���xffx��f~f�������f���f��f���~f�~f�xffx��f~f�������f����f��f�������ff���fx~f�f��`�����f���f���f���ff���ff�fx�fx���������f����f��ff���ff���fx���������f����f��f����ff��"

To the terminal or similar.

Again, no such issues with pronterface.

Thank you so much, this issue is driving me crazy.

[skorokithakis]

This has nothing to do with the power supply or the disconnection. It is a bug in Octoprint, however, but needs a different issue. The workaround here is to press connect, then disconnect, then connect again, and it will connect right away the second time.

[synman]

@skorokithakis what you're reporting, and the post before yours, are different issues that what was originally reported here. Disconnection WHILE printing means a connection was already established and something caused it to drop.

The issue you are reporting is you try to connect, the connection attempt hangs, you have to abort it, and try again. Typically upon your second attempt it immediately connects.

I mention this because myself (and many others) have the same problem. It appears when setting up the serial connection that a connection timeout is not being set, or honored.

I would have thought that there was already connection retry logic built into octoprint. I have not looked at the code but from my experience it is as if it is attempting to open and write/read a port with an infinite (likely no) timeout set.

Perhaps we should open another issue ...

[ntoff]

@synman I don't know if it's the same thing but I've also had that issue where it fails to connect the first time, I just disabled the auto reset on the atmega (put a small capacitor between reset and ground or something) and it connects first time every time. Only have this issue on one printer, other printer works fine. I reckon some arduino bootloaders must add a few extra seconds to make uploading a sketch easier or something, but then octoprint just goes "hmm, whatever this thing is, it still isn't talking to me so I'll move on".

[synman]

The Wanhao i3 has a similar jumper and it was the first thing I pulled. With the auto-reset jumper enabled I was not able to connect to my printer using any software, S3D, Cura, Repetier Host, and OctoPrint.

[foulowl]

I realized also, I have not had any random disconnects, the printer now stays connected for long periods of time with no issues, but the initial connect is what is troublesome.

[foosel]

Perhaps we should open another issue ...

Yes, please do! It doesn't make sense to keep changing the subject of an issue like it is happening here. One ticket per problem, not one endless ticket of "and this also causes me problems". Otherwise it's impossible to keep an overview of things, to keep a meaningful change log and so on, and also for others to find the ticket to report the same problem in with information that might help to identify the issue on hand!

When you do open another ticket for the "Initial connection takes too long, then fails, subsequent connect immediately succeeds" issue, keep this in mind please: I need as many logs (serial.log specifically, but also octoprint.log) as possible and the configured timeout settings plus information on the specific printers/printer controllers and firmware with version and preferable a link to the source that show that behaviour in order to be able to debug this. I've never seen that behaviour myself with any of my printers unless the firmware was stuck in an extra long reset, so apparently my test set doesn't allow reproduction. My current guess is it's a case of "printer is sending a long line of binary data on reset for whatever reason" (hence the read timeout that is in fact set doesn't trigger), but I need way more information than what is currently available to me to be able to confirm or eliminate that wild guess.

[skorokithakis]

Good call, opened #1770.

[ian2000611]

First 2-3 posts were very helpful. My issue turned out to be power.

[Mr-Newlove]

my issue turned out to be power as well, but mine was due to vibration from the printer causing the pis USB to shake, and losing connection for such a small amount of time it didn't reboot the pi, but would interrupt the printing. adding a zip tie to keep pressure on the connector fixed it for me.

[ir-fuel]

Should I post it here since the ticket is "closed"?
I just had another random disconnect but I am running Octoprint on a Raspberry Pi connected to its original power supply. Cables all look good too.

Send: N23481 G1 X122.715 Y105.678 E0.00982*98
Recv: ok
Send: N23482 G1 X122.647 Y105.380 E0.00982*101
Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2025
Please see https://bit.ly/octoserial for possible reasons of this.
Changing monitoring state from 'Printing' to 'Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2025'
Connection closed, closing down monitor

There is nothing in particular to be seen in octoprint.log

[ir-fuel]

Second question, related to this. If I upload the gcode file to the SD card through OctoPrint and I launch the print, would a disconnect also cause the printer to stop printing?
I love this tool, but if I have to risk losing multi-day prints because of random disconnects it's just not worth it unfortunately.

[ntoff]

Disconnecting shouldn't interrupt an SD print, but reconnecting most likely will, however neither is guaranteed either way because the behaviour depends entirely on how your control board handles serial activity.

Arduinos are so easy to program because they reset themselves on serial activity. Some printer control boards based on atmega chips don't bother with the arduino compatibility and thus probably won't suffer from the auto reset (these would be incredibly hard to program, often requiring a 3rd party ICSP device to upload firmware, and contain no bootloader), some do auto reset to keep the ease of programming but have a jumper to disable it.

Either way if you're doing a long print and octoprint happens to be unreliable for you, I'd disconnect and manually start the print from the printer's LCD panel (assuming it has one)

[ir-fuel]

Yeah that's indeed the best solution for now unfortunately. I just ran 3 small prints today (1.5h each) and the 3rd one disconnected. I had it happen yesterday too so I switched the power supply from a powered USB hub (that should give enough amps) to an original Raspberry Pi one (which, I found out, does not give 5V but 5.1V). Didn't happen anymore so I thought it was solved.

This is the kind of stuff that's really hard to debug, because it happens seeming randomly.

FYI, I am connected to a Prusa i3MK2S MMU.

I guess I can't manually launch a timelapse recording while not connected to the printer?

[JohnOCFII]

FYI, I am connected to a Prusa i3MK2S MMU.

What firmware version are you running on the MK2S? There have been lots of serial communication issues (more so with the MK3) recently, especially with firmware 3.1 and higher. This ticket is so old, and OctoPrint has had enough changes since this ticket was closed almost a year ago, that if you still have issues, I'd open a new ticket.

[ir-fuel]

I'm running 3.1.0

[JDCodeIt]

I too have experienced the random disconnect. It seems we should consider a design change such that the print continues. Should the software copy to the SD then request the printer to print from the SD card, then acting as a monitor of messages coming out?
When a disconnect happens, the printer should continue to print from the SD. Upon reconnect, the current print in progress should not be interrupted.
Is the trouble in the limitations of the firmware interface or in OctoPrint's implementation of the connect / disconnect process?

The snappy web interface for your 3D printer
Version 1.3.6

Send: N23952 G1 X42.364 Y19.947 E4.36865*98Recv: ok 23952Send: N23953 G1 X42.826 Y19.807 E4.37432*100Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2025Please see https://bit.ly/octoserial for possible reasons of this.Changing monitoring state from 'Printing' to 'Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2025'Connection closed, closing down monitor

[ir-fuel]

The problem is that the printer stopping on reconnect is in the printer firmware, not OctoPrint.

Also, copying to SD is incredibly slow.

On 12 Jan 2018, at 15:22, JDCodeIt <[email protected][e-mail]> wrote:

I too have experienced the random disconnect. It seems we should consider a design change such that the print continues. Should the software copy to the SD then request the printer to print from the SD card, then acting as a monitor of messages coming out?
When a disconnect happens, the printer should continue to print from the SD. Upon reconnect, the current print in progress should not be interrupted.
Is the trouble in the limitations of the firmware interface or in OctoPrint's implementation of the connect / disconnect process?

The snappy web interface for your 3D printer
Version 1.3.6

Send: N23952 G1 X42.364 Y19.947 E4.3686598Recv: ok 23952Send: N23953 G1 X42.826 Y19.807 E4.37432100Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2025Please see https://bit.ly/octoserial for possible reasons of this.Changing monitoring state from 'Printing' to 'Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2025'Connection closed, closing down monitor

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/foosel/OctoPrint/issues/1603#issuecomment-357250598, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABgDU7LxA2NBQ2-j8mTqqWY8zZjLXMCLks5tJ2qggaJpZM4K9C4c.

[JDCodeIt]

Is my suggestion even possible with the interface - copy the file to the SD, then request it to print from the SD file? This should at least allow the print to complete if there is a disconnect at some point. Maybe you can't monitor progress under those conditions, but at least the print has a better chance of completing.

I confirmed on my printer that from a cold start of the printer, initial connect to the board resets the Arduino. Pulling the USB plug does not reset the board - OctoPrint reports the unexpected error from loss of communication. Plugging the USB in again resets the Arduino.

So it only would work if we prevent the serial from re-connecting. Maybe that is not possible to control?

[ir-fuel]

You should try copying a 20mb model through OctoPrint to the SD. It takes forever.

On 12 Jan 2018, at 16:11, JDCodeIt <[email protected][e-mail]> wrote:

Is my suggestion even possible with the interface - copy the file to the SD, then request it to print from the SD file? This should at least allow the print to complete if there is a disconnect at some point. Maybe you can't monitor progress under those conditions, but at least the print has a better chance of completing.

I confirmed on my printer that from a cold start of the printer, initial connect to the board resets the Arduino. Pulling the USB plug does not reset the board - OctoPrint reports the unexpected error from loss of communication. Plugging the USB in again resets the Arduino.

So it only would work if we prevent the serial from re-connecting. Maybe that is not possible to control?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/foosel/OctoPrint/issues/1603#issuecomment-357263393, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABgDU1HQJmrvJASELS2Enprlr6QYaeugks5tJ3YEgaJpZM4K9C4c.

[CrashSerious]

I've hit this 3 times on a print in the last 36 hours. Running 1.3.6 on the OctoPi distribution With a minimal X Environment running, but nothing running when the issue occurs. (I didn't even have a web browser installed until I started troubleshooting this issue)

The first time I wasn't able to salvage the print, I think because it had cooled completely and ended up getting layers peeling up. (oddly enough I tried exactly what was mentioned earlier by editing the gcode. (So, I'm glad the logs prints that line out to them. Yes, I do somewhat agree it could be unsafe to automatically do this.) The second time I was able to continue successfully, but was not near the print when the error occurred... until it happened again. I noticed it right away and had top running. and Noticed octopi running near 100% CPU (Image attached) I don't recall doing anything on the PI

I am running a Raspberry Pi 3, dedicated to printing. Nothing else happening on the Pi. I have the Printer (Stock ANet A8) plugged into the Pi's USB ports, along with a USB Hub (Separately powered) , and an additional USB device (K40 Laser Cutter) that was powered off completely via a surge protector (again separate surge protector). In the Hub, I do have a web cam plugged into a USB hub (powered separately) but was not viewing the camera either by a stream of a plug in (control), along with a flash drive and a Wireless keyboard and mouse. Again the USB hub is an active hub and powered separately.

For Power, I have a 5 volt 15 Amp Arcade power supply dedicated to the Pi. I have two sets of 24 AWG (I double checked) cables running from the Supply to power the Pi via the GPIO pins each with separate power and ground connections to the GPIO pins. (They are using headers, I doubt that could be the problem since there are multiples but have considered soldering directly to the board or etching a custom PiHat with terminals. to avoid every possibility.) Someone could say it's providing dirty power. I've tested that as well with my Rigol DS1054Z and it appears to be providing clean power every time I have checked. No I didn't have a scope on it this very time, but have in the past when I've noticed the lightening bolt on the screen to trouble shoot. The lightening bolt also appears to happen when the CPU is under load I noticed.

While we are On power... Jamesh (who appears to be a Raspberry Pi Foundation Engineer) says here talking to the USB device increases power consumption (https://www.raspberrypi.org/forums/viewtopic.php?t=159679 " (e.g. talking to a USB device)")

At any rate the third time I was close by and hear the printer stop after 2-3 hours of running. I had suspected that maybe the printer was for some reason spontaneously rebooting or disabling steppers, so I sat there on my PC in my lab waiting. Oddly enough, the printer hadn't rebooted (a reboot would have stopped the print immediately and as quickly as I turned around I would have seen it happening on the LCD since the screen goes all light and a text "animation" shows as it starts up. None of that happened, it just said "ready". Then I immediately looked at the monitor and the lightening bolt was there and octoprint was consuming 100% resources and python was consuming close to that based on the 'top' instance I had running for the last two hours. (Pic of one window attached) I don't recall doing what I was doing in the second image that did the same thing with respect to CPU resources since the print was working, so I suspect it's a different thing.

Unfortunately, this is ALL I have for information on that instance. The second instance I have more... but it may be a separate issue and I only bring it up here since I saw similar things happening with processes in top the first go round, but I was not uploading gcode the first go round the only thing happening was printing.

I "fixed up" the gcode quickly (5 minutes maybe) and uploaded the file to octoprint through the web interface. The second thing I noticed was the lightening bolt was doing it again. This time I ran 'ps aux| grep python' and noticed that there was a gcode analysis python script running as well. This was eating a large portion of the CPU in addition to the octoprint consuming CPU. I only mention it because if someone was doing that... well, "that's going to leave a mark"so to say. That Python script should be "nice"ly spawned if it isn't, it's a beast it seams.

Whew.... that was a long one. Hopefully, I have provided some additional information or helped in someway to show I'm not some random guy who said "hay muh printes diedz". I've done my homework on this, I'm not saying it's octoprint necessarily-- but I am saying I can't rule anything out at this point. Also, I made a backup of the entire OctoPrint and oPrint folders in case anything there is helpful. Let me know if there is something else I can upload.

At this point, I'm printing that print from SD with OctoPi Connected to see if it does the same thing doing nothing. (I did see it go from 1.1% to 7.0% in top for some reason a bit ago.)

[CrashSerious]

Drat. The second Image above is the third image I grabbed after the analysis script completed. (just up arrowed the ps aux) This is the second image. (apologies...)

[joshnd82]

I had almost given up on using octoprint because I was getting so many serial disconnects that I could rarely stay connected for more than 30mins.

I tried every solution I could find in all the forums: official PI power supply (rated 2.5A or more); various USB cables; fixing the usb connector to my printer USB port so there was no chance the connection could wobble around while printing; adding additional shielding around the USB cable and PI; adding vibration dampening under the PI and printer.

I was about ready to give up when I had one more idea. In my work in the past with digital electronics with an AC power source, I have sometimes seen noise coupling into the digital circuits through the AC ground line. The PI power supply only has a two prong 110V power connection (i.e. no connection to 110V GND) but my printer (the Creality CR-10) has a 3 prong power connector, meaning that it's connected to the 110V GND.

To make a long story short I put a 3 prong to 2 prong adapter (like this) on my printers power supply cable so that the GND wouldn't be connected to the 110V GND and now octoprint has run for weeks without any disconnects. My theory is that noise was coupling from the AC GND line into the DC circuits of the printer, and would eventually cause issues for the printer's sensitive USB communications when the noise would get particularly bad. I haven't seen any mention of this kind of possible fix in any of the other threads online, so I thought it was worth mentioning so that it could be added to the list of things worth trying.

[ir-fuel]

Isn't that dangerous?

[ian2000611]

Short answer: Yes...

Long answer:

In the case of a 3d printer the case of the power supply is grinded which
also ground a few points on the per supplies circuit board. This ground MAY
be connected to the frame off the printer if you have a metal frame. This
ground is a safety mechanism to reduce (not eliminate) the possibility of
electrocution. Unless the circuit board in your power supply gets unscrewed
and contacts the the case or your in the habit of sticking metal objects in
to you powrer supply it is unlikely that it will ever server lurks purpose.

The ground is much more important for shop tools like a drill because
drills get dropped regularly and have significantly higher chances of a
short to the case occurring.

It is also worth noting that it you cut an ungrounded electrical cord, org
melt it's insulation the ground will offer simmer protection.

Grounding is required on all electrical outlets because you never know what
is going to be plugged in and if it requires a ground to be safe.

In the particular case of a 3d printer I would argue that out is a good
idea to have a ground, but that if you are getting dirty powrer from you
ground it is relatively low risk to remove it.

I would argue that the ground wrote be disconnected in the printer in order
to still provide protection to the cord since that is the moist likely
point inn the system to have an issue.

On Sat, Mar 31, 2018, 04:12 ir-fuel [e-mail] wrote:

Isn't that dangerous?

On 31 Mar 2018, at 08:57, joshnd82 <[email protected] [email protected]>> wrote:

I had almost given up on using octopi because I was getting so many serial
disconnects that I could rarely stay connected for more than 30mins. I
tried every solution I could find in all the forums: official PI power
supply (rated 2.5A or more); various USB cables; fixing the usb connector
to my printer USB port so there was no chance the connection could wobble
around while printing; adding additional shielding around the USB cable and
PI; adding vibration dampening under the PI and printer; etc. I was about
ready to give up when I had one more idea. In my work in the past with
digital electronic I have sometimes seen noise coupling into the digital
circuits through the AC ground line. The PI power supply only has a two
prong 110V power connection (i.e. no connection to 110V GND) but my printer
(the Creality CR-10) has a 3 prong power connector, meaning that it's
connected to the 110V GND.

To make a long story short I put a 3 prong to 2 prong adapter (like this<
https://www.amazon.com/CableWholesale-Wholesale-Grounding-Converter-30W1-32200/dp/B000I96AUM>)
on my printers power supply cable so that the GND wouldn't be connected and
now octoprint has run for weeks without any disconnects. Thought I would
mention this in the thread so that anyone having this issue could add one
more thing to the list of things to try if you're having serial disconnect
issues.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<
https://github.com/foosel/OctoPrint/issues/1603#issuecomment-377671644>,
or mute the thread<
https://github.com/notifications/unsubscribe-auth/ABgDU2a6F4XtMtv8R_8AMZpAqHrqxi2bks5tjyjqgaJpZM4K9C4c>.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/1603#issuecomment-377675678,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPhcmGDZPoOxp-iMZgm0tBX75v4EJpsks5tjzqLgaJpZM4K9C4c
.

[mvasilakis]

Have you tried adding a ferrite choke to the USB and/or the power cables? Just a thought.

[ir-fuel]

@ian2000611 , don't be so sure about this. I think it is very bad advice and very dangerous to suggest people to bypass ground on their 3d printers!
Check this video to see what happens when you remove ground:

https://www.youtube.com/watch?v=3jYZDLOV4Jc

[Almidi]

Greetings
I believe this is the best place to report my problem. Correct me if I'm wrong
I have a problem with my Octoprint Setup, and I cant seem to find anyone else having the same issue.
The octoprint is running on a Pi3, and it has never ever disconnected during a print... but when a reboot on the reaspberry occurs (due to updating the OS etc. ) the printer refuses to connect.
The strange part is that the octoprint detects the printer on port /dev/ttyUSB0, but when I just unplug and replug the cable, the printer is detected on port /dev/ttyUSB1, and the connection is established flawlessly. I have tested the connection for 2 weeks of continuous printing, and there hasn't been any problems whatsoever..

The error i get is
Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2605)

Also the seria log
2018-12-11 12:01:02,746 - Enabling serial logging 2018-12-11 12:01:05,915 - Changing monitoring state from "Offline" to "Detecting serial port" 2018-12-11 12:01:05,940 - Serial port list: ['/dev/ttyUSB0'] 2018-12-11 12:01:05,941 - Connecting to: /dev/ttyUSB0 2018-12-11 12:01:05,946 - Changing monitoring state from "Detecting serial port" to "Opening serial port" 2018-12-11 12:01:05,949 - Connected to: Serial<id=0x69133f70, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor 2018-12-11 12:01:05,950 - Starting baud rate detection... 2018-12-11 12:01:05,950 - Changing monitoring state from "Opening serial port" to "Detecting baudrate" 2018-12-11 12:01:06,956 - Trying baudrate: 115200 2018-12-11 12:01:06,968 - Send: N0 M110 N0*125 2018-12-11 12:01:16,981 - Baudrate test retry #1 2018-12-11 12:01:17,003 - Send: N0 M110 N0*125 2018-12-11 12:01:18,003 - Baudrate test retry #2 2018-12-11 12:01:18,025 - Send: N0 M110 N0*125 2018-12-11 12:01:18,034 - Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2605 2018-12-11 12:01:18,038 - Please see https://faq.octoprint.org/serialerror for possible reasons of this. 2018-12-11 12:01:18,045 - Changing monitoring state from "Detecting baudrate" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2605)" 2018-12-11 12:01:18,058 - Connection closed, closing down monitor

[foosel]

The strange part is that the octoprint detects the printer on port /dev/ttyUSB0, but when I just unplug and replug the cable, the printer is detected on port /dev/ttyUSB1,

No, your operating system detects your printer in these ports, OctoPrint only lists what your OS detects.

I suggest to look into the syslog and figure out why the device is switching, maybe the first connect has the machine boot up in some bootloader mode that would also explain the error.

In any case, stuff like this is better directed at the community forums at discourse.octoprint.org

[kourindouhime]

I think best solution is to add reconnecting and resuming the print. I woke up today and saw my printer stuck

[QuibblingAsh42]

Not sure if I should open a new issue or not, but dropping in to report this started happening to me today. I'm NOT using a Pi, though. I've got OctoPrint running on Linux Mint 18.3 on an old laptop I had in the closet. I'm using the same USB cable I've been using for the last week without issue (it's a new prrinter). Dmesg output below, anything else I can provide?

[ 5819.212135] usb 8-2: new full-speed USB device number 2 using uhci_hcd
[ 5819.598135] usb 8-2: New USB device found, idVendor=1a86, idProduct=7523
[ 5819.598139] usb 8-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 5819.598141] usb 8-2: Product: USB2.0-Serial
[ 5821.621996] usbcore: registered new interface driver usbserial
[ 5821.622013] usbcore: registered new interface driver usbserial_generic
[ 5821.622022] usbserial: USB Serial support registered for generic
[ 5821.643664] usbcore: registered new interface driver ch341
[ 5821.643682] usbserial: USB Serial support registered for ch341-uart
[ 5821.643703] ch341 8-2:1.0: ch341-uart converter detected
[ 5821.651154] usb 8-2: ch341-uart converter now attached to ttyUSB0
[ 7482.312088] usb 8-2: USB disconnect, device number 2
[ 7482.312542] usb 8-2: ch341_read_int_callback - usb_submit_urb failed: -19
[ 7482.312570] usb 8-2: failed to send control message: -19
[ 7482.315199] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 7482.315207] ch341 8-2:1.0: device disconnected
[ 7482.620078] usb 8-2: new full-speed USB device number 3 using uhci_hcd
[ 7482.793614] usb 8-2: New USB device found, idVendor=1a86, idProduct=7523
[ 7482.793617] usb 8-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 7482.793619] usb 8-2: Product: USB2.0-Serial
[ 7482.795663] ch341 8-2:1.0: ch341-uart converter detected
[ 7482.803656] usb 8-2: ch341-uart converter now attached to ttyUSB0
[14915.864419] usb 8-2: USB disconnect, device number 3
[14915.864915] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[14915.864956] ch341 8-2:1.0: device disconnected
[45491.788055] usb 8-2: new full-speed USB device number 4 using uhci_hcd
[45491.962108] usb 8-2: New USB device found, idVendor=1a86, idProduct=7523
[45491.962112] usb 8-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[45491.962114] usb 8-2: Product: USB2.0-Serial
[45491.965166] ch341 8-2:1.0: ch341-uart converter detected
[45491.973192] usb 8-2: ch341-uart converter now attached to ttyUSB0
[97214.168344] usb 8-2: USB disconnect, device number 4
[97214.168775] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[97214.168807] ch341 8-2:1.0: device disconnected
[97214.576123] usb 8-2: new full-speed USB device number 5 using uhci_hcd
[139858.640078] usb 8-2: new full-speed USB device number 6 using uhci_hcd
[139858.818115] usb 8-2: New USB device found, idVendor=1a86, idProduct=7523
[139858.818119] usb 8-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[139858.818121] usb 8-2: Product: USB2.0-Serial
[139858.821179] ch341 8-2:1.0: ch341-uart converter detected
[139858.829193] usb 8-2: ch341-uart converter now attached to ttyUSB0
[158605.824083] usb 8-2: USB disconnect, device number 6
[158605.824928] usb 8-2: ch341_read_int_callback - usb_submit_urb failed: -19
[158605.827195] usb 8-2: failed to send control message: -19
[158605.829435] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[158605.829448] ch341 8-2:1.0: device disconnected
[158606.368029] usb 8-2: new full-speed USB device number 7 using uhci_hcd
[158606.542102] usb 8-2: New USB device found, idVendor=1a86, idProduct=7523
[158606.542104] usb 8-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[158606.542106] usb 8-2: Product: USB2.0-Serial
[158606.547828] ch341 8-2:1.0: ch341-uart converter detected
[158606.555234] usb 8-2: ch341-uart converter now attached to ttyUSB0
[162359.801898] usb 8-2: USB disconnect, device number 7
[162359.803545] usb 8-2: failed to send control message: -19
[162359.807849] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[162359.807896] ch341 8-2:1.0: device disconnected
[162360.360043] usb 8-2: new full-speed USB device number 8 using uhci_hcd
[162360.540061] usb 8-2: New USB device found, idVendor=1a86, idProduct=7523
[162360.540063] usb 8-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[162360.540064] usb 8-2: Product: USB2.0-Serial
[162360.543138] ch341 8-2:1.0: ch341-uart converter detected
[162360.551144] usb 8-2: ch341-uart converter now attached to ttyUSB0

[intramorph]

Yeah this happened to me today as well and it just stopped printing in the middle of the print... 2 times... It was printing fine but all of a sudden i had other windows open on my pc but that can't be the issue though. It will randomly just stop in the middle of print and 5 hrs+materials lost. :/

[jprucks]

I understand that this issue may have multiple causes, but it's the top search result for this error, so I'd like to contribute the solution for my printer.

My printer gave the same error and would randomly act like it was shorting out (and reboot or just shut down).
After replacing the power supply, Arduino, and RAMPS board, I finally tracked it down to a dead hotend heater. Apparently it was shorting out while hot. Any movement would cause it to short, killing the print by shutting down either the Arduino or RAMPS board.

So, if you get this error with other visible signs of a short somewhere, check the heaters.

[pagu99]

I had a similar problem. After weeks of successfull usage, Octoprint randomly started loosing USB connection during print. When switching to the original power supply the problems are gone.

[truefranco]

I just upgrade to Marlin 2.0 final from Marlin 2.0.x bugfix and this problem start to happen. Rolling back to Marlin 2.0.x bugfix to make sure.