Error message when there is communication problems

[stema12]

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:

1. Most common: Octoprint puts up an error message saying it cannot connect to printer.
2. Second most common: A message saying "Firmware is corrupt, do you want to update the firmware" appears. If I click "No", the message disappears and there is no connection. If I click "Yes", the firmware is downloaded and a new connection attempt is done. It ends with an error message as in 1. above.
   It would seem unlikely that the firmware would continue to be corrupt, I've probably clicked yes five or six times now.
3. Unusual, but it has happened several times: One of a few Python Exceptions is shown, either in the Terminal window or in the console octopi was started from. They are referenced below.

Branch & Commit or Version of OctoPrint

1.2.14

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

https://gist.github.com/stema12/a84199337805900697ee379e2d9f6c51

Link to contents of terminal tab or serial.log

https://gist.github.com/stema12/4d89e5b49658a11cf4333a0e3b12aeda

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).
So if self._comm is None, the code on line 941 that uses that variable will throw an exception, because state_string doesn't exist.
The error message looks like this:
https://gist.github.com/stema12/098f5637831a438eca0fd9b01aa41771

I'm rolling back to 1.2.13 to see if I can get it going again, It seemed more stable.

[GitIssueBot]

Hi @stema12,

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!

Best regards,
~ Your friendly GitIssueBot

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.

[foosel]

The first issue is definitely a problem in the M33 Fio plugin, the write method of its serial object replacement is not returning the bytes written (it should though). The same problem exists with the current release of the GPX plugin.

The state_string issue is fixed in commit 444a36d.

[foosel]

I pushed a workaround to accommodate plugins not returning the count of written bytes to the maintenance branch, together with the state_string fix and a preliminary fix for the issues tracked in #1423. Please test this ASAP and report back if it solves your problems, I'd like to be sure it does before pushing get-well-release 1.2.15, which I want to do today.

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:

cd ~/OctoPrint
source ~/oprint/bin/activate
git fetch
git checkout maintenance
python setup.py clean
python setup.py install
sudo service octoprint restart

---

Instructions for manual install which followed the setup guide:

cd /path/to/OctoPrint
source venv/bin/activate
git fetch
git checkout maintenance
python setup.py clean
python setup.py install

• restart OctoPrint

[donovan6000]

I can confirm that the changes to the maintenance branch works well with M33 Fio.

[foosel]

@donovan6000 thanks for reporting back

[stema12]

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.
This, to me, means that there is no major malfunction in the hardware at least.

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):

https://gist.github.com/stema12/9e2d995b82c1d89100e7c92ba57fbada

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.
I tried sending the message "N0 M110 N0_125" in serial.log just to see what happens, but I only get a "?" in return.
However, if I send "M420 T0_" (which I think is "turn off the LED"), I get "B004" in return, but the LED stays on. So I seem to have some kind of connection.

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?

[stema12]

I just managed to get an error that shows up as an unhandled exception in octoprint.log. It might be useful.

octoprint.log:
https://gist.github.com/stema12/8b1a272d43fa607efe02fb1568505c17

serial.log
https://gist.github.com/stema12/9fe4e750103dcc71bdec01e649f4af1c

[donovan6000]

This is an M33 Fio and not an OctoPrint issue. Try out the devel version of M33 Fio to see if fixes the issue. When connecting to the printer leave both the serial port and baud rate set to auto.

[stema12]

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:
https://gist.github.com/stema12/fa152426db996aedee4a37b943855db6

plugin_m33fio_debug.log looks like this:
https://gist.github.com/stema12/4af5567d7a595ecf18611b483474f01a

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:

1. Press "Connect". Octoprint says "firmware is corrupt, update?", i click "no".
2. Press "Connect". Octoprint says "firmware is corrupt, update?", i click "no".
3. Press "Connect". Octoprint says "firmware is corrupt, update?", i click "Yes"
4. Octoprint updates firmware, says it is successful.
5. Octoprint tries to connect to ttyACM1, fails with a message saying it could not connect (log says Device or Resource busy) and tells me to power cycle the printer.
6. I power cycle it (as in the instructions for M3D I first disconnect USB, wait 10 seconds, then turn power off, wait 10 more seconds, then connect the USB, then turn on power).
7. Press "Connect", octoprint looks like it connects (but uses 115200 in the log?), switches mode to "operational", but i.e. the LED on/off buttons do nothing. Also, no real response from printer in log.
8. Press "Disconnect". Octoprint seems to be busy but goes to "Disconnected" mode after some timeout.
9. Press "Connect", printer actually seems to connect, gets a few responses, but as soon as I try to press a button in the control tab, nothing happens and octoprint terminal log says there is a timeout.
10. Press "Disconnect" with the same result as 8.
11. Press "Connect" and several error messages appear, leaving the "Connect" button disabled.

[stema12]

Update: Sometimes when I power cycle the printer, I get
usb 2-1.3.2: string descriptor 0 read error: -32
in dmesg | tail.

But far from always.

[stema12]

And now I got this in octoprint.log:
https://gist.github.com/stema12/943e77d2300afc3bbf9ab76f370dc3f9

When this was happening in serial.log:
https://gist.github.com/stema12/61accbfd3178ea854e1741ef4bd2d6f5

[stema12]

Ok, this is weird.

When pressing the "Connect" button, what often happens is that I see USB disconnect in dmesg, and then immediately a new full-speed USB device number <#> using ehci_hcd, and the device jumps between ttyACM1 and ttyACM0.

Is that supposed to happen?

[stema12]

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.

octoprint.log:
https://gist.github.com/stema12/dc6730658b9953ef644e67da917e2720

plugin_m33fio_debug.log
https://gist.github.com/stema12/5d456115d7769ebe9b32a8f48131ae34

serial.log
https://gist.github.com/stema12/2ecca81e537ce37a8a375a60ed1b0a25

[donovan6000]

Not really sure what's causing this. You do have the Micro 3D udev rule applied, right?

[donovan6000]

Also, it is normal for the printer to change it's serial port location, ttyACMx, whenever it switches between bootloader and firmware mode. So what your experiencing with that is normal.

[stema12]

The udev rule is applied. On both computers. I just tried changing the group to dialout in the rules file just to see what happens but it behaves identically to when group is set to users.

Looking in plugin_m33fio_debug.log, there are a lot of responses of type rs 65536, is that also normal?

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 ok back from printer, then it just stops responding.

[donovan6000]

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?

[chrisgwilliams]

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.

[chrisgwilliams]

Rebooted Pi and cycled power to printer, logged in, reconnected and within 1 minute, same error.

[foosel]

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.

[donovan6000]

Ok, I opened an issue at M33 Fio's issue tracker where we can continue this discussion.