Issues with OctoPrint >= 1.2.14

[donovan6000]

A continuation of our discussion from here

Make sure your all using the latest version of M33 Fio, which at the time of writing this is V1.4, if your having issues with OctoPrint >= 1.2.14.

[stema12]

I have been busy with some other stuff today, but I went by the store and bought another SD-card so I could write an Octopi image on it. The Octopi installation (on a RPi-3) works well, so apparently I have done something wrong while installing OctoPrint and M33-Fio on my other computers. Probably the same mistake(s), since they behave identically.

If you are still interested in troubleshooting (not really necessary if I am the only one with this problem, I will either buy another Rpi or dig deeper into my installation procedure and try to find what I did wrong), here is the info you asked for:

Linux-distros: LinuxMint 17.3 (64-bit) and Ubuntu 14.04 (64-bit) Printer version (this is the string I get from the printer): Micro3D FIRMWARE_VERSION:2016040401 MACHINE_TYPE:The_Micro

I did not install using the M33-Fio installer, I used the method described on Octoprints GitHub page: first clone the git repo, then install using virtualenv, start OctoPrint in virtualenv and then install M33-Fio from the plugin manager in OctoPrint. Apart from that, I also added my user to the groups tty and dialout (not strictly necessary), and added the udev rule as described in installers/Linux.

Would it be a good idea to install using the M33-Fio installer instead? Would it then be good or bad to use another virtualenv folder an installing into that?

Please note that I will be on a business trip monday-friday and while I will receive updates on this issue via mail and can answer questions, I will not be able to test anything with the hardware until friday evening (CET) at the earliest.

[chrisgwilliams]

Looks like I'm on M3D Fio 0.34, so a bit behind on the version. I'm still new to the OctoPi life, so forgive me if I ask dumb questions. How do I upgrade? I don't see a way to do so via the OctoPi PlugIn Manager (and unfortunately, I'm running headless for the next week or two due to a move.)

[donovan6000]

@stema12 I'll see if I can get the same issues by recreating your setup in the next few days. I'll let you know if I have any other question. I've never actually followed the installation steps, so that might be related to the problem.

M33 Fio's Linux installer doesn't setup a virtualenv. It just installs everything into the users Python environment.

@chrisgwilliams You'll need to uninstall M3D Fio and install M33 Fio. You can uninstall M3D Fio in OctoPrint's plugin manager by clicking the garbage can icon next to M3D Fio, and you can install M33 Fio with OctoPrint's plugin manager by searching for it in OctoPrint's plugin repository.

[donovan6000]

@stema12 I was able to recreate the problems you were experiencing when I didn't have the Micro 3D udev rule applied, so you probably didn't have it applied correctly. Ubuntu and LinuxMint both come with ModemManager preinstalled. ModemManager attempts to communicate with all the devices mapped to the computer's /dev/ttyACMx ports, and that was causing all your problems since multiple programs were communicating with the printer at the same time. The udev rules sets it so that ModemManager ignores the printer which prevents that issue from occurring.

[stema12]

Ok, I will try again when I get home on friday.

I know that the udev rule is in /etc/udev/rules.d/ on both computers, because I double checked it when you mentioned it. I actually don't remember if I rebooted or not, I thought the sudo udevadm control --reload-rules and sudo udevadm trigger would trigger the change.

[stema12]

I'm grateful @donovan6000 that you took the time to look at this, but it wasn't actually the udev rule that was the problem.

I updated to the latest versions of Octoprint and M33-Fio, and also replaced the rule file (even though it looks the same), but it didn't work.

Sadly, I don't really know what the problem was, just that a clean new install of OctoPrint and M33-Fio, including deleting the ~/.octoprint folder did the trick. Just deleting the ~/Octoprint folder (where Git put the code and where setup.py was run) and reinstalling didn't help, neither did only deleting the ~/.octoprint folder.

How I managed to get the same problem on two computers is beyond me, but maybe it was something with the versions I used that broke something somewhere at some point.

Now I'm on Octoprint 1.2.15 and M33-Fio 1.5 and everything works just fine. Except for a few things that are more related to the usage of the plugin. What forum is best for asking such questions?

[donovan6000]

Awesome! Glad you got it working.

There's discussions about M33 Fio at M3D's forum and at Thingiverse's forum where you can ask questions about it.

[antonioluppi]

I had the same problem after installing Octoprint and the M33-Fio plugin. As stema12 suggested, I removed the Octopart installation and installed it again following the steps on the install.sh from M33-Fio (just executing the script got me stuck on a loop/deadlock, probably because I'm on a amd64 and not on a RPi)

Maybe the problem is in the M33-Fio Plugin?

[donovan6000]

@antonioluppi I'm still leaning towards this being a problem with the udev rule not being applied correctly which is allowing ModemManager to try communicating the printing at the same time as OctoPrint does. Can someone experiencing this problem can run sudo apt-get purge modemmanager to see if that resolves the issue? That will either confirm or deny this being an issue with the udev rule not bring applied.

Installing M33 Fio via OctoPrint's plugin manager doesn't install the udev rule since it doesn't have root privileges during the installation, so it'll always require the user to install the udev rule if they install M33 Fio with the plugin manager.

I don't own a Raspberry Pi, and all my testing with install.sh has been on an amd64 running Ubuntu 16.04. Can you post terminal output so I can see where you were getting a deadlock?