Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Error message when there is communication problems #1425
What were you doing?
I was trying to connect to my 3D-printer, a Micro3D.
What did you expect to happen?
For Octoprint to connect to the printer.
What happened instead?
Having tried many times and a few different things happen:
Branch & Commit or Version of OctoPrint
Printer model & used firmware incl. version
Micro3D FIRMWARE_VERSION:2016040401 MACHINE_TYPE:The_Micro
Browser and Version of Browser, Operating System running Browser
Chromium 51.0.2704.79 Built on Ubuntu 14.04, running on LinuxMint 17.3 (64-bit)
Link to octoprint.log
Link to contents of terminal tab or serial.log
I have only had the M3D for a day, but I haven't been able to connect to it long enough to actually print anything yet. It is a bit annoying.
It might be connected to M33-Fio, since it is an M3D, but the error messages point more to octoprint, that's why I create the issue here.
Having looked at some of the error messages, I think I've found a bug in octoprint/printer/standard.py in the class method Printer.on_comm_state_change().
There is an if-statement on line 921 that will not set state_string unless (self._comm is not None).
I'm rolling back to 1.2.13 to see if I can get it going again, It seemed more stable.
It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).
If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.
I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2016-08-11 21:00) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!
PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.
referenced this issue
Jul 29, 2016
I pushed a workaround to accommodate plugins not returning the count of written bytes to the
Also pinging @xunker here due to the upvote there indicating an investment in the issue.
Update instructions as follows.
To give this a whirl on OctoPi:
Instructions for manual install which followed the setup guide:
I'm sorry, but this doesn't work for me. But I guess it is an issue mostly with M33 Fio, not OctoPrint?
I've spent all evening trying different settings, different USB ports and different versions of octoprint and M33 Fio, but I can't get a stable connection. I also tried another computer with pretty much identical results. OctoPrint 1.2.13/M33 Fio 1.2 are the versions that sometimes gets a connection long enough to try some commands, like turning on and off the fan, LED and move the print head around a bit. It looses the connection relatively fast though, I've never been able to start a print with it. (I'm sorry but I don't have a serial.log for that session, it seems to disappear when I do "python setup.py clean".)
I have checked that the printer (and computer, a Lenovo X220) is actually working by finding the harddrive that came with the laptop that has Windows 7 on it. Using that and downloading the official M3D software, I was able to connect to the printer and do a small test print that took about an hour.
If I can find the time this weekend, I'll see if I can't take one of my RPi:s and install octopi on it. That would rule out any mistake I might have done during installation.
The maintenance branch/M33 Fio 1.3 is however most stable in how the error presents itself. It almost always says that the firmware is corrupt and that it needs updating. Here is what comes up in serial.log at such an event (and me clicking "No" to updating between lines 4 and 5):
Why is it trying to send after the connection is closed? Or am I misinterpreting the log?
I have also tried connecting using GtkTerm manually to ttyACM3. It puts up a warning that the hardware might not support 250000 bps, but it seems to connect successfully.
One strange thing that happens is that if I say "yes" to downloading new firmware, it says the download went fine, then it tries to reconnect to ttyACM4 (which is present in /dev/, it seems to re-enumerate one ACM number higher after firmware update), fails with "OSError: '[Errno 16] Device or resource busy:", then the "Connect" button remains disabled ( = greyed out and non-clickable). Refreshing the page enables the "Connect" button. That seems a bit weird. Either the button should remain disabled after refresh or the enabling of the button is missing in some event-path in the software.
I'm not really sure how to proceed from here. Should this be moved to M33 Fio, left here, or if noone else can recreate it, close it and I'll just have to figure something out myself?
I just managed to get an error that shows up as an unhandled exception in octoprint.log. It might be useful.
I updated to devel version of M33 Fio and also 1.2.15 of OctoPrint. No luck.
It still says that the firmware is corrupt and needs to be downloaded. After downloading (which really shouldn't be needed by now...) there are a few successful connections, but nothing that stays useable for more than a few seconds.
There are no error messages in octoprint.log; serial.log looks like this:
plugin_m33fio_debug.log looks like this:
That it connects to ttyACM0 now is because this is on my main computer, not the laptop in the previous logs. It gives the same result though.
The operational sequence done for the logs is as follows:
And now I got this in octoprint.log:
When this was happening in serial.log:
Ok, this is weird.
When pressing the "Connect" button, what often happens is that I see
Is that supposed to happen?
Ok, I'm just throwing logs in here, maybe some of it could be useful. In the beginning of these logs, exactly what I described in the previous comment happened. It did a USB disconnect when enumerated as ttyACM0 and reappeared as ttyACM1. M33 Fio seemed to track it though.
The udev rule is applied. On both computers. I just tried changing the group to
Looking in plugin_m33fio_debug.log, there are a lot of responses of type
There is a change in that I haven't gotten a message about the firmware being corrupt all day. Now it always behaves the same way: Starts to connect, gets one
rs 65536 isn't normal. That means the printer is telling OctoPrint to resend it the command with the line number 65536, but OctoPrint hasn't sent a command with that line number so it doesn't make sense.
Let me try to recreate your setup so I can see if I get the same problems. What Linux distro are you using? What printer firmware and version are you using? Did you use M33 Fio's Linux installer to install OctoPrint, or did you install OctoPrint in some other way?
I'm having an issue with my Micro3D as well. I was on 1.2.13 and everything was great.
I skipped 1.2.14, and installed 1.2.15 and now I can't stay connected to my printer anymore.
I get this message "Offline: Too many consecutive timeouts, printer still connected and alive?" within 2 minutes of connecting to my printer, every time.
The initial compatibility problem has been solved in 1.2.15. Direct connections to regular printers work fine. So my guess is the issues that you are experiencing have something to do with how the M33 Fio plugin does things, and that's better handled by @donovan6000 than by me (and hence also over on the M33 Fio issue tracker considering that I a) don't have an M3D myself and b) don't have any insight in what the plugin even needs to do in order to be able to talk with the printer from regular OctoPrint (and also don't have the resources to change that). So I'm marking this as closed now as I actually thought I did yesterday morning (again, original issue was fixed, if any, this is a new one anyhow). You can still comment even on a closed issue, but I strongly suggest to rather take this to the plugin's tracker.
Regarding the consecutive timeouts: For now you can just disable consecutive timeout tracking (Settings > Serial > Advanced Options, set the last three entries ("Max. consecutive timeout...") to 0, save, reconnect). I'm not sure that will solve your problem though since timeouts occur when the printer doesn't respond anymore, and that indicates something's amiss usually. My guess would be that the output visible in the Terminal tab might help to pinpoint the actual issue, but again, I don't know what the plugin changes about how things present themselves here, so that might be a total shot in the dark.