Ender 3 wont connect to octopi

What is the problem?
I currantly have octoprint up and running on a raspbeery pi. I can connet to it via octopi.local just fine. i have the webcam up and running. I cannot however get my ender 3 to connect to it. it says "Error: Failed to autodetect serial port, please set it manually.". i have read a lot of forums and cannot seem to find a solution that works. might I add I had it connected about 6 months ago. now it won't connect for the life of me. the serial port drop-down menu does not have any other options other than auto. when i try to connect to the printer I leave the baudrate and serial port on auto.

What did you already try to solve it?

  • reinstall and setup octoprint
  • tried many mini USB cables with no success.
  • read plenty of forums and troubleshot just about everything that's in my skill set to do.

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)

Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: []
Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."
Failed to autodetect serial port, please set it manually.
Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: []
Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."
Failed to autodetect serial port, please set it manually.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)

I am running windows 10, a raspberry pi 3b+, and octoprint 1.4.0

thank you so much for your help, it means a lot. so sorry if I left something out. I hope this can be resolved.

One thing to check, the opening in the processor case of Ender 3’s, for the usb connector, is a little small. In my case, the usb cable would almost plug in, but not quite. Sometimes I could connect, but not always. I tried several cables, but could not get a consistent connection. It would sometimes disconnect in the middle of a print. I ended up using a knife to trim the plastic around the usb cable connector. That solved the problem for me. Don’t ask how long it took me to figure this out.

I just gave it a shot, and although that makes sense, it did not work for my situation. thanks for the idea though!

Try to power on your Ender before you power on your Pi

I just gave that a shot and had the same result.

Login via ssh, disconnect your printer, connect it again, enter dmesg | tail -n 20 and post the output here.

Let's see if the pi detects it at all.

pi@octopi:~ $ dmesg | tail -n 20
[   11.033855] 8021q: 802.1Q VLAN Support v1.8
[   11.706006] Adding 102396k swap on /var/swap.  Priority:-2 extents:1 across:102396k SSFS
[   11.774203] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   11.774336] brcmfmac: power management disabled
[   12.195987] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   12.195996] 8021q: adding VLAN 0 to HW filter on device eth0
[   18.527905] Bluetooth: Core ver 2.22
[   18.527955] NET: Registered protocol family 31
[   18.527958] Bluetooth: HCI device and connection manager initialized
[   18.527972] Bluetooth: HCI socket layer initialized
[   18.527979] Bluetooth: L2CAP socket layer initialized
[   18.527998] Bluetooth: SCO socket layer initialized
[   18.568594] Bluetooth: HCI UART driver ver 2.3
[   18.568602] Bluetooth: HCI UART protocol H4 registered
[   18.568644] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   18.568755] Bluetooth: HCI UART protocol Broadcom registered
[   19.012825] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   19.012832] Bluetooth: BNEP filters: protocol multicast
[   19.012848] Bluetooth: BNEP socket layer initialized
[   23.910695] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
pi@octopi:~ $ ^C
pi@octopi:~ $

mhmm there is nothing at all :thinking:

Does your pc detect the printer?

What would be the best way to test that?

Well the first thing would be whether you're hearing the new device detected sound or not.

If that works you could try to move the axis with something like
https://www.pronterface.com/

Also, with the printer off, when you plug the USB into your pi, does the display on the printer power on? if so, you need to use the strip of electrical tape over the + power pin of the USB to keep it from feeding power into the printer. And with the printer connected and powered on, ssh in and do a sudo lsusb
what is the output of that?

1 Like

It does power the display when the printer is off. I will check that when I get back to the office on Monday. Thanks for the tips.

There is no need to that. It just prevents underpowering the pi when the printer isn't turned on.
That's why we tested to turn the printer on first.
Of course I would also recommend doing the tape thing - just saying it isn't a mandatory mod.

That's what we checked with dmesg.

I thought again about your problem and it might be possible that you got a bend pin.
I guess you already tried different usb ports on the pi so I would check the connector on the printer.

I have inspected the plug and don't see anything out of place. all pins look to be good.

It could be your cable, I had similar trouble until I located a cable with the ferrite filters. The tape mod on pin 1 is recommended as it'll stop the challenges of powering the printer off and killing the Pi, as I found out the hard way.

The other thing I found was ground loops, which the ferrite filters probably managed to minimise induced noise to get by, but didn't fully solve the problem.

If you don't have a secure ground on the two devices you can have a potential develop between the Pi and the printer, more so if they are plugged into different power sockets. (I found this as the flood light with a metal case I was using on the printer (physically connected) had a dodgy plug pack and was creating a 4v AC ground loop).

Best answer is to connect the Pi ground to the printer ground (on the main board) so that this doesn't impact the signal path. The thing to do BEFORE doing that is to us a meter to test the difference in potential so you don't fry anything.

Also too, you need to be able to see the /Dev/USBxxx device in the OctoPrint connect menu, if this is not appearing then you may have additional USB issues.

And if you have enabled the Pi UART because you modded it for the button (how I found it on the Pi4B) or because it's enabled by default, OctoPrint polls the UART (TTY Device) before the USB device and fails when the TTY device doesn't respond. There are threads on these issue elsewhere in here.

I mean the connector on the printers mainboard.

@jhale716
those are things we could do if the connection isn't stable or if we get some special TTY names.
As you can see in the dmesg output there is no connection detected at all.

I did inscription the main board connection. It all checks out. Any way to test it? Maybe volt meter?

I'm not really the right guy for this question - you could damage your board if you do the wrong thing.
@OutsourcedGuru might be able to answer it :slight_smile: