Octoprint 1.2.10 + GPX Plugin || [Errno 5] Input/output error' @ comm.py:_do_send_without_checksum:1918

[IAmOrion]

As discussed on the Octoprint Issues, I have moved this here to the GPX Plugin.

Printer: CTC Dual with Sailfish 7.7 Octoprint: 1.2.10 "Release" GPX Plugin: 2.4.1

Here are some example GCode files created from Simplify3D:

https://www.dropbox.com/s/9cdumnsgcjcmcu1/3687.gcode?dl=1 ... 28.8mb https://www.dropbox.com/s/ce8jlpallsgkadl/HeadsetBracket.gcode?dl=1 ... 1.3mb https://www.dropbox.com/s/2itvesf3in4wm7q/OddBits.gcode?dl=1 ... 36.7mb

As previously mentioned, I do not believe this to be an issue with a specific command (or if it is, it must be one that's repeated many times but fails randomly) since the same print can stop during the outline, at 1%, or 95% and anywhere in between.

If you want or need anymore details just let me know.

Config.yaml: https://www.dropbox.com/s/ftj5tj9jv51ei1a/config.yaml?dl=1 GPX.ini: https://www.dropbox.com/s/5u085sbmoked5mh/gpx.ini?dl=1

Although I don't believe it to be any setting issue since having downgraded to Octoprint 1.2.9, I am printing perfectly again (I have completed some small, 20 min prints and also a 19 hour print prefectly)

-=-=-=-=-={ Copied from Octoprint Issue: https://github.com/foosel/OctoPrint/issues/1286 }=-=-=-=-=-

What were you doing?

Simply Printing... the error occurs at random points during the print. I can repeat the same print, it can fail at 1%, 4%, 10%, 90% etc etc - there seems to be no exact point.

What did you expect to happen?

To finish printing.

What happened instead?

It failed. The print fails with the following information in the console

Unexpected error while writing to serial port: IOError: '[Errno 5] Input/output error' @ comm.py:_do_send_without_checksum:1918 Changing monitoring state from 'Printing' to 'Error: IOError: '[Errno 5] Input/output error' @ comm.py:_do_send_without_checksum:1918' Closing down send loop Connection closed, closing down monitor

http://pastebin.com/uzWYr2qx

With version 1.2.9 I NEVER had this issue, since updating to 1.2.10 yesterday it has happened on every single print, failing at what seems like random times.

NOTE:

I use Octoprint on 2 Pi's with 2 printers. A Wanhao Duplicator i3 and a CTC Dual running Sailfish 7.7. BOTH are running the latest 1.2.10.

The Wanhao Duplicator i3 does NOT have this problem. It prints fine without issue. As bizarre as this is, it does, for now, seem to be related to the CTC Running Sailfish.

Branch & Commit or Version of OctoPrint

1.2.10

Printer model & used firmware incl. version

CTC Dual, Sailfish 7.7

Browser and Version of Browser, Operating System running Browser

Opera

Link to octoprint.log

For some reason, my Octoprint.log is 206 bytes with no information

Unexpected error while writing to serial port: IOError: '[Errno 5] Input/output error' @ comm.py:_do_send_without_checksum:1918 Changing monitoring state from 'Printing' to 'Error: IOError: '[Errno 5] Input/output error' @ comm.py:_do_send_without_checksum:1918' Closing down send loop Connection closed, closing down monitor

Link to contents of terminal tab or serial.log

http://pastebin.com/uzWYr2qx

Unexpected error while writing to serial port: IOError: '[Errno 5] Input/output error' @ comm.py:_do_send_without_checksum:1918 Changing monitoring state from 'Printing' to 'Error: IOError: '[Errno 5] Input/output error' @ comm.py:_do_send_without_checksum:1918' Closing down send loop 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.

[IAmOrion]

I just wanted to add more to this (again) I though going back to 1.2.9 had resolved my issues, but it didn't! I mean, it's more stable, however last 3 prints have failed at seemingly random places and I'm at a loss as to why. I've tried a new cable, I've tried routing the cable a different way, but I keep getting the same bloody error!

I don't know how possible this is, but is there any way to implement a "resume" function if this happens? I had a 17 hour print, stop at 96% with 38 mins remaining because of this error and no way to somehow carry on form where it stopped. I wish I knew the best solution here, but this is driving me insane!

I wonder if there's some residual issues from the upgrade/downgrade? For whatever reason, my setup had been working flawlessly... the problem happened almost instantly after upgrading to 1.2.10 and it does infact appear to remain after downgrading to 1.2.9 so I've no idea what the hell is up :(

I'm going to re-image the SD Card with a fresh OctoPi img (but will stay on 1.2.8 or whatever the version is on the distro)

[markwal]

Thanks for getting back with that additional info. It rules out a change in OctoPrint, I think.

As we suspected, it must have something to do with the plugin. We've talked about building a resume function, but there are some snags relating to the extrusion axis position and not knowing easily exactly what state everything is in (for example, while OctoPrint knows what temperature you're at, it doesn't know whether your cooling fan is on or not). Also, there's a bit of a problem in that the movement commands are queued, so OctoPrint doesn't know which one your printer was actually doing when the bad thing happens.

I imagine there's a way to build some more resiliency into the GPX plugin. Might take me some testing, etc. so it might be a while before I have something to test and since I don't reproduce the problem you're having, it'll be hard to tell whether I'm actually making your particular issue better. Until then, you might want to print from the SD card in the printer.

It's too bad it only happens after being a long way in on a print because it'd be nice to get a verbose GPX log on the failure, but those things get big really fast and big ones cause problems of their own.

I wonder if you're having a power problem. Just a little bit of a power sag causing problems with either the RPi's USB power for communication or the printer's motherboard glitching just long enough to kill it. You have a CTC right? I thought I read somewhere that they're a little close to the bone on their power supply, so if the heat bed kicks in a just the wrong moment, you have troubles.

[IAmOrion]

The printer in question IS a CTC correct. It's so very strange though as I've been printing perfectly fine for the last 3 months. It literally started when I upgraded to 1.2.10

The Pi is using a 5v 2.1a USB plug which should be more than enough. The only other thing, changed in the last week is that I have a roll of ABS that I'm using. And for my CTC to work well with ABS, my bed is 120 and my extruder is 250... maybe that's a potential issue that ties in with what you've just said about the power supply. So many variables I feel this may be nigh-impossible to track down entirely. That also being said, I had completed around 10 ABS prints with these settings without issue... it really does seem to tie in with when I updated (and partially remained after downgrading again) but I'm just lost as to what it could be. I'm literally re-imaging the Pi now, I will try and get a print going tonight and hen report in the morning.

EDIT: I've enabled the verbose gpx log - will see if the print fails or not over night.

[IAmOrion]

Ooookay, so the "default" Octoprint version that is included in the OctoPi image is Octoprint 1.2.2

I've installed the GPX plugin.

As soon as I hit print I'm now faced with an entirely new error for me!

Unexpected error while reading serial port: IOError: '[Errno 5] Input/output error' @ comm.py:_readline:1319 Changing monitoring state from 'Printing' to 'Error: IOError: '[Errno 5] Input/output error' @ comm.py:_readline:1319' Connection closed, closing down monitor

Now, that may well be because I'm using an outdated Octoprint build of course but I'm not sure to be honest.

I retried the same print, this time It failed with the same old error - so whatever is happening it's possible the octoprint 1.2.10 update was coincidental

Serial.log : http://pastebin.com/Fc4dazMK plugin_GPX.log : http://pastebin.com/kTRqZ8sY GPX.ini : http://pastebin.com/0p8DizUs

let me know if there is any other files you would like to see.

FYI: I should recap on what I've tried and tested / checked.

I've replaced USB cable (3 times), I've re-routed USB Cables path, I've changed Pi power supply twice, I've swapped SD Cards, I've taken the printer apart and made sure all cables are seated correctly (I've checked twice) < not really sure if there's anything left to check other than over the weekend, I shall retry something in PLA and see if there is a problem. I no longer think Octoprint has any issue, I think that was purely circumstantial so I may update my latest re-imaged SD card to 1.2.10.

I'm currently printing via SD card now tonight just to rule out any s3d slicing anomalies (I'm using the same file [well, it's x3g version since I always create gcode and x3g because I kept forgetting to uncheck the option ha] that has failed everytime via Octoprint / GPX plugin)

[markwal]

OK, thank you for the verbose plugin_GPX.log. It looks like what we need is a retry on read failure. You should turn off verbose and delete that log file and then click the "disconnect" then "connect" button in the OctoPrint UI to reload the GPX module. Having a big log file like that can increase the likelihood that you'll have a failure.

[markwal]

The reason, I think, that GPX doesn't retry that read is that if it lost a response, it can only get another one if it writes the command again. But if it does that you'll get an extra extrusion where it isn't wanted. Could be bad on a long move. The protocol doesn't have a packet identifier so the bot can't check to see if it is a repeat. I wonder if it is better, in the interest of resiliency to err on the side of over extrusion or on the side of skipped moves... hmmm....

Are you interested in running a test version of the plugin?

[IAmOrion]

Hi Mark,

I hate to say this, BUT it would actually I was wrong to think this was a GPX Plugin issue. I tried a few prints via SD Card last night directly on the printer - it still failed. :( This of course instantly rules out Octoprint and the GPX plugin now.

I am so sorry I didn't try it sooner (I'll blame it on myself having a senior moment) but alas, it does mean GPX can not be the culprit. I've loaded my second extruder with PLA and am now about to set a PLA print going. You may have been right when you said about the power supply.

I will report back asap...

Additional, ok, printing with PLA at much lower temp makes no difference. Something else must have died. I've ordered a new power supply, and will pull it apart over the weekend.

Again, I am very sorry for incorrectly concluding the GPX Plugin was the problem.

[markwal]

OK. Still considering making the serial a bit more robust, but considering this issue occurs printing with the SD card, it looks like something on the bot is happening.