New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Octoprint randomly disconnects from printer #1603

Closed
foulowl opened this Issue Nov 27, 2016 · 53 comments

Comments

@foulowl

foulowl commented Nov 27, 2016

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

This comment has been minimized.

Owner

foosel commented Nov 27, 2016

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

This comment has been minimized.

foulowl commented Nov 27, 2016

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

This comment has been minimized.

Owner

foosel commented Nov 28, 2016

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

@foulowl

This comment has been minimized.

foulowl commented Nov 28, 2016

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

Thank you!!

@skorokithakis

This comment has been minimized.

skorokithakis commented Nov 29, 2016

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

This comment has been minimized.

Owner

foosel commented Nov 29, 2016

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

This comment has been minimized.

Owner

foosel commented Nov 29, 2016

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

This comment has been minimized.

skorokithakis commented Nov 29, 2016

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

This comment has been minimized.

foulowl commented Nov 29, 2016

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

@skorokithakis

This comment has been minimized.

skorokithakis commented Nov 30, 2016

@foulowl, what's your baud rate?

@skorokithakis

This comment has been minimized.

skorokithakis commented Nov 30, 2016

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

This comment has been minimized.

Owner

foosel commented Nov 30, 2016

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

@skorokithakis

This comment has been minimized.

skorokithakis commented Nov 30, 2016

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

This comment has been minimized.

Contributor

ntoff commented Nov 30, 2016

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

This comment has been minimized.

skorokithakis commented Nov 30, 2016

@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

This comment has been minimized.

skorokithakis commented Dec 1, 2016

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

This comment has been minimized.

shacal commented Dec 1, 2016

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

This comment has been minimized.

Contributor

ntoff commented Dec 2, 2016

@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

This comment has been minimized.

skorokithakis commented Dec 5, 2016

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

This comment has been minimized.

Owner

foosel commented Dec 5, 2016

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

@skorokithakis

This comment has been minimized.

skorokithakis commented Dec 5, 2016

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

This comment has been minimized.

Owner

foosel commented Dec 5, 2016

Hehe, will do ;)

@foosel

This comment has been minimized.

Owner

foosel commented Jan 27, 2017

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

@foosel foosel closed this Jan 27, 2017

@foulowl

This comment has been minimized.

foulowl commented Jan 30, 2017

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�~����~���������xf�x�������������~f�����fx����������f�����������f�x���������x��������������������~�������f���������f�f���ff��xffx��f�f������������f����f������������x�x��f�������x�f������������������������f���������f�f���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���fxf�f��`�������f������f����f���f�f���ff��fx���fx�������������f������f��f�f���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 comment has been minimized.

skorokithakis commented Jan 30, 2017

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.

@ntoff

This comment has been minimized.

Contributor

ntoff commented Feb 5, 2017

@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

This comment has been minimized.

synman commented Feb 5, 2017

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

This comment has been minimized.

foulowl commented Feb 9, 2017

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

This comment has been minimized.

Owner

foosel commented Feb 13, 2017

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

This comment has been minimized.

skorokithakis commented Feb 13, 2017

Good call, opened #1770.

@ian2000611

This comment has been minimized.

ian2000611 commented Oct 18, 2017

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

@theshadow124

This comment has been minimized.

theshadow124 commented Oct 29, 2017

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

This comment has been minimized.

ir-fuel commented Jan 6, 2018

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

This comment has been minimized.

ir-fuel commented Jan 6, 2018

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

This comment has been minimized.

Contributor

ntoff commented Jan 6, 2018

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

This comment has been minimized.

ir-fuel commented Jan 6, 2018

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

This comment has been minimized.

JohnOCFII commented Jan 6, 2018

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

This comment has been minimized.

ir-fuel commented Jan 7, 2018

I'm running 3.1.0

@JDCodeIt

This comment has been minimized.

JDCodeIt commented Jan 12, 2018

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

This comment has been minimized.

ir-fuel commented Jan 12, 2018

@JDCodeIt

This comment has been minimized.

JDCodeIt commented Jan 12, 2018

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

This comment has been minimized.

ir-fuel commented Jan 12, 2018

@CrashSerious

This comment has been minimized.

CrashSerious commented Mar 25, 2018

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.

20180324_175655

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.

20180324_180801

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

This comment has been minimized.

CrashSerious commented Mar 25, 2018

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...)
20180324_180439

@joshnd82

This comment has been minimized.

joshnd82 commented Mar 31, 2018

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

This comment has been minimized.

ir-fuel commented Mar 31, 2018

@ian2000611

This comment has been minimized.

ian2000611 commented Mar 31, 2018

@mvasilakis

This comment has been minimized.

mvasilakis commented Mar 31, 2018

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

@ir-fuel

This comment has been minimized.

ir-fuel commented Mar 31, 2018

@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

This comment has been minimized.

Almidi commented Dec 11, 2018

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

This comment has been minimized.

Owner

foosel commented Dec 11, 2018

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

This comment has been minimized.

kourindouhime commented Jan 5, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment