Communication error Wanhao I3 Pi3

#1

So I've been using octoprint for some time now, didn't get round to printing much in the last 3 months or so, booted up back in December and updated octoprint, which is where all my issues started (or so it seems)

Basically at random points octoprint gets a Communication error and the printer halts but continues heating the hot end and bed.

"Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves."

I've tried multiple new cables and power supplies (for pi) just in case but no avail, have checked it's not my printer (not tested usb as there is no way to test other than connecting to a pi?) by printing the same files I was trying to print via sd card, all of which printed fine with no issues at all. Also went with a fresh install just in case and backed up my files and settings via the settings tab then imported them once the fresh install was ready and up to date, so i'm unsure if there's something I copied back over that's causing this or not.

Have enabled serial logging but that doesn't really show any error at all, the syslog does show something though at the same time that the printer loses comms

Syslog

Jan 7 16:14:23 octopi kernel: [ 6922.879810] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 7 16:14:23 octopi kernel: [ 6922.879824] usb 1-1.2: Product: FT232R USB UART
Jan 7 16:14:23 octopi kernel: [ 6922.879835] usb 1-1.2: Manufacturer: FTDI
Jan 7 16:14:23 octopi kernel: [ 6922.879845] usb 1-1.2: SerialNumber: AI05TD19
Jan 7 16:14:23 octopi kernel: [ 6922.888392] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
Jan 7 16:14:23 octopi kernel: [ 6922.888628] usb 1-1.2: Detected FT232RL
Jan 7 16:14:23 octopi kernel: [ 6922.891918] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
Jan 7 16:14:23 octopi mtp-probe: checking bus 1, device 6: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Jan 7 16:14:23 octopi mtp-probe: bus: 1, device: 6 was not an MTP device
Jan 7 16:17:01 octopi CRON[2272]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jan 7 16:29:06 octopi kernel: [ 7805.962400] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Jan 7 16:29:06 octopi kernel: [ 7805.962499] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Jan 7 16:29:27 octopi systemd[1]: Created slice User Slice of pi.
Jan 7 16:29:27 octopi systemd[1]: Starting User Manager for UID 1000...
Jan 7 16:29:27 octopi systemd[1]: Started Session c2 of user pi.
Jan 7 16:29:27 octopi systemd[2471]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jan 7 16:29:27 octopi systemd[2471]: Listening on GnuPG cryptographic agent (access for web browsers).
Jan 7 16:29:27 octopi systemd[2471]: Reached target Timers.
Jan 7 16:29:27 octopi systemd[2471]: Reached target Paths.

Going off the serial log (snippet below)

2019-01-07 16:29:06,578 - Send: N6284 M10531
2019-01-07 16:29:06,601 - Recv: ok 6283
2019-01-07 16:29:06,607 - Send: N6285 G1 F2640 X112.022 Y32.509 E807.81463
5
2019-01-07 16:29:36,614 - Communication timeout while printing, trying to trigger response from printer. Configure long runn$
2019-01-07 16:29:36,625 - Send: N6286 M10529
2019-01-07 16:30:06,630 - Communication timeout while printing, trying to trigger response from printer. Configure long runn$
2019-01-07 16:30:06,642 - Send: N6287 M105
28
2019-01-07 16:30:36,663 - Communication timeout while printing, trying to trigger response from printer. Configure long runn$
2019-01-07 16:30:36,675 - Send: N6288 M10519
2019-01-07 16:31:06,695 - Communication timeout while printing, trying to trigger response from printer. Configure long runn$
2019-01-07 16:31:06,709 - Send: N6289 M105
18

Unsure on where to go from here now, confident it's not the printer at fault or the cables or power supply as they've worked fine for everything, the only other thing I have done it created a script so on boot the wifi does not sleep when not used by disabling the wifi power management.

Any suggestions?

#2

I'm experiencing the exact same issue. Hopefully we can shed some light.

#3

Just a bit of further info, so after seeing a post asking about asking about monitoring for sd card prints I thought i'd give that a go, first print went fine with no issues, 2nd print however continued to print but octoprint reports comms error again

Recv: SD printing byte 339395/3447947
Send: N2061 M2735
Recv: ok 2061
Recv: SD printing byte 339928/3447947
Send: N2062 M27
32
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
Please see https://faq.octoprint.org/serialerror for possible reasons of this.
Changing monitoring state from "Printing from SD" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2605)"
Connection closed, closing down monitor

#4

By any chance do you have anything else connected? such as a camera via the ribbon cable or a usb device?

#5

I'm using a pi cam with ribbon cable. I found another thread on this issue here.

Going to try some of these suggestions as well.

1 Like
#6

Funny, I forgot to mention it, but I am also using the same, have disconnected now and running a test print, all good so far

Scrap that, spoke to soon, failed with camera disconnected, gonna disabled time lapse and try again

#8

Hmm. I'm seeing the same in mine i3 plus. Are you running stock firmware or a differing marlin fork?

#9

Complete stock, looked at the firmware upgrade process, seems a lot to lay out if you don't already own the equipment.

#10

Not really, I upgraded mine to ADV I3++, all I needed was some free software, a spare SD card and the ability to plug a computer into the printer. This vid lays it out beautifully.

#11

Searching for this error turns up an issue on the Raspbian repository.

"I can confirm that the problem with serial port disconnects that express the syslog line:
ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
is caused by FAKE FTDI chips. I tried several different FTDI usb serial boards, and it turned out that they were all fake. I purchased genuine FTDI serial board (UB232R) from Digikey, and the problem has gone away. I can verify that the batches that I had originally tried were fake because several of them had SerialNumber of 00000, and several others had serial number of A50285BI, which was confirmed to be common with fake chips - see https://softsolder.com/2016/09/02/counterfeit-ftdi-usb-serial-adapter-roundup/

I did not have to drop the USB down to 1.1, it worked correctly as soon as I put in the genuine chips."

#12

Thanks for taking the time to reply, sorry I haven't replied back, forgot all about this since i've been printing via SD.

So if i were to get this for instance https://uk.rs-online.com/web/p/interface-development-kits/0429262/

How easy are they to change over?

Thanks for your help

#13

Dunno, dude. I can barely remember January. :laugh:

1 Like
#14

lol, thanks for your help anyway, made me take my printer apart at least just to check it, seems it's just one big board inside, doesn't look replaceable for that part at least, unless at component level.

Reprap board I believe, no idea on much else, have cleaned the USB anyway inside and out with some ISO just to see if it was dirty inside, fans pulling dust in etc, will lowering the baudrate possibly help too?

Also I checked the serial number in that thread you linked to mine and seems it's genuine, different to the linked anyway.

The FTDI it's using is FT232RL

#15

Return to the original post where you include foosel's link to how to troubleshoot serial errors, follow that link and see if there's anything you could do to help the situation.

#16

This is on the board just after the usb connector and controller https://cpc.farnell.com/ftdi/ft232rl/ic-usb-to-uart-smd-ssop28-232/dp/SC10141 does the USB to Serial.

Is there anything else that could cause sudden disconnects of serial, the machine is still functioning from the lcd display, it maintains it's heat settings and the menus work, so it's not the printer locking up, it's just not receiving the commands, I think from everything I've read anyway.

I've tried new cables, new psu for the pi.

One other thing, i'm printing via sd card fine with no stops, but isn't the sd also controlled via the usb controller, that in turn goes to the usb to serial?

The serial seems genuine, from the output, do they just go bad or could there be something else?

I'm capable of installing the new FTDI but just want to be sure it's that.

#17

And you walked through the seven bullet points of foosel's post (to include the last one)?

#18

Yep, well all except the last one about limiting it to 1.1 speeds, I run a camera and have done for months previous to this, so would prefer not to, as i said in my opening post, it seems this has happened after I last updated octo, but i tried a fresh install, which still resulted in the same issue.

Which led me to believe it's a kernel problem? but seeing as it's not widespread that seems unlikely

#19

Even do that one as well. If you know that crippling the serial speed down to nothing fixes it, then this is a troubleshooting step. It would suggest that you need a good-quality cable or that there is a problem in one of the chips.

#20

Cable i'm using is shielded, so i'm confident that's not the issue, will try reducing the speed and post back.

#21

Right, so my config.txt looks like this

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=fe6e5bb9-02 rootfstype=ext4 ele$
dwc_otg.speed=1

I added the dwc_otg.speed=1 as a separate line, should it be on the same line, or should it not make difference.

It didn't work with that anyway, printer done a few prints uptime was about 2 hours before a disconnect again.

One other thing I haven't mentioned, when the disconnect happens the log shows the printer wasn't replying, if I click connect on the left side like I would if i'd just started up, it connects again with no issues and will continue until the next disconnect.

Last edit: More info, even if the printer is not printing anything and I leave it idle, it will disconnect then too, not sure what this would mean exactly.