Trying to get this work in a docker container

[endotronic]

Thanks for the amazing work! I have been using M33-Fio with much success on Ubuntu Server for a while. Today I'm trying to get Octoprint with M33-Fio working in a docker container hosted on CoreOS. It looks like I'm going to have a few questions during this process, though. Mind helping out a bit with some answers? Of course, if I get this working, I'll share my results.

For starters, I downloaded and applied the udev rules from your Linux subdirectory. I created a privileged container that shares /dev/bus/usb with the host (if you're not familiar with docker, don't worry about this). Inside of the container, I see this when I run lsusb: Bus 008 Device 002: ID 03eb:2404 Atmel Corp.

Since the ID matches the vendor ID from the udev rules, I'm guessing that the drivers for the serial chip loaded. However, I don't see any new tty devices in /dev, should I see /dev/ttyUSB0 or something? Octoprint in the container is not able to auto-detect the M3D printer. Any ideas what I should try next to debug this?

[donovan6000]

What does running the following command output when the printer is connected?

python -c "import serial.tools.list_ports;print serial.tools.list_ports.comports()"

[endotronic]

Interestingly, serial was not available and I had to install python-serial. Anyway, the output was: [('/dev/ttyS3', 'ttyS3', 'n/a'), ('/dev/ttyS2', 'ttyS2', 'n/a'), ('/dev/ttyS1', 'ttyS1', 'n/a'), ('/dev/ttyS0', 'ttyS0', 'n/a')]

Any ideas what needs to happen to make serial available? I have a feeling that Ubuntu probably has drivers for this Atmel chip that CoreOS does not have. Do you happen to know what the Atmel chip is or where I can find the driver?

[donovan6000]

The printer uses a standard CDC USB descriptor, so it should be using the cdc-acm driver that's built into the Linux kernel.

What's the last few lines outputted by running the following command right after you plug in the printer? Does it show any errors related connecting to the printer?

dmesg

Ideally it should show something like this.

236956-[244025.710611] usb 2-1.1: new full-speed USB device number 65 using ehci-pci
237034-[244025.805916] usb 2-1.1: string descriptor 0 read error: -32
237097-[244025.805927] usb 2-1.1: New USB device found, idVendor=03eb, idProduct=2404
237176-[244025.805931] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
237260:[244025.806514] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device

[endotronic]

I should have checked the kernel logs sooner :(

[55660.438551] usb 8-1: new full-speed USB device number 3 using uhci_hcd [55660.593603] usb 8-1: string descriptor 0 read error: -32

I'll play around with this, but honestly, there's no real reason why I'm on CoreOS versus something like Ubuntu Server; I may likely just set up docker on Ubuntu Server soon, and I anticipate that may solve my problems. I'll report back here and close the issue. Thanks for your help so far.

[endotronic]

I had a few minutes to try again to get Octoprint with M33-Fio running in a docker container. This time I'm on Ubuntu Server (Xenial) and Ubuntu recognizes the serial device and creates /dev/ttyACM0 without issue. I can pass this into the container, and python sees it just fine:

root@a4bc6dadb139:/data# python -c "import serial.tools.list_ports;print serial.tools.list_ports.comports()" [('/dev/ttyACM0', 'ttyACM0', 'USB VID:PID=03eb:2404')]

When I try to connect, the status changes to "Detecting baudrate" for a little while before it fails. The console output from Octoprint doesn't include anything useful (there isn't a single message outputted).

Any ideas come to mind how I can proceed debugging? Don't waste too much time thinking... I haven't given up yet!

[donovan6000]

Does OctoPrint's log show any errors related to M33 Fio? It's in ~/.octoprint/logs/octoprint.log.

[endotronic]

Ah... yes. 2017-01-08 07:09:24,145 - octoprint.plugin - ERROR - Error while calling plugin m33fio Traceback (most recent call last): File "/usr/local/site-packages/octoprint/plugin/__init__.py", line 204, in call_plugin result = getattr(plugin, method)(*args, **kwargs) File "/usr/local/site-packages/octoprint_m33fio/__init__.py", line 5392, in on_event self.setFileLocations() File "/usr/local/site-packages/octoprint_m33fio/__init__.py", line 5090, in setFileLocations "/home/" + os.environ["USER"] + "/.octoprint/checkout" File "/usr/local/lib-python/2.7/UserDict.py", line 40, in __getitem__ raise KeyError(key) KeyError: 'USER'

Looks like I don't have it installed properly. I see the issues - I'll work on these. Thanks again.

[donovan6000]

Your OS doesn't set a USER environmental variable. I thought that always existed in Linux, so I didn't add any exception handling for if it doesn't exist. I'll fix it when I get home from work tonight. In the mean time you can comment out this line and see if you get any other M33 Fio errors.

[donovan6000]

I added environmental variable exception handling to M33 Fio's devel branch. You can install it using OctoPrint's plugin manager to install a plugin from this URL:

https://github.com/donovan6000/M33-Fio/archive/devel.zip

[endotronic]

Thanks so much! I'll give this a shot as soon as I can tomorrow. The docker environment is pretty weird like this, but I can add environment variables as needed.

[endotronic]

No more plugin errors, but the serial communication is not working right inside of the docker container. It appears to send "M110" and does not get a response. Unfortunately I think I'm giving up, at least for now. I really appreciate your help with this. If someone wants to pick up where I left off, the repository is here: https://github.com/endotronic/docker-octoprint

[donovan6000]

The problem is that the printer disconnects and reconnects when it switches between bootloader and firmware mode, so the docker contain needs to have access to all devices. I was able to get it to connect to the printer by launching the container with the following commands: --privileged --volume=/dev:/dev

[endotronic]

Ah, great! I'll give that a shot. I was using --privileged but did not treat /dev as a volume (I thought privileged basically did this).

[endotronic]

I confirmed that -v /dev:/dev makes connecting work. There seems to be an issue with the menu system. I'll try to fix it and add a README when I get a chance. Thanks again for your help.