SKR Mini E3 V3 not connecting to octoprint

What is the problem?

I can't get a connection between the SKR Mini E3 V3 and octoprint.

What did you already try to solve it?

Tried a data only usb cable, tried different firmware.

Printer connects effortlessly in windows, on both cura and pronterface. Device is showing up in linux as "STMicroelectronics Virtual COM Port". usb connection showing up under ttyACM0. Just hangs on "Opening serial connection". Baudrate is set correctly in both firmware and in octoprint. My creality 4.2.2 board works no problem on the same setup without restarting or anything, plug in, refresh, connect and boom it works. switch back to my main printers usb and back to the stalling. It's almost like the board just doesn't have the proper linux driver or the driver its using isn't utilizing the hardware correctly. As mentioned earlier the windows drivers are functioning as intended.

Have you tried running in safe mode?

Yes, no difference

Did running in safe mode solve the problem?

no ):

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!) (9.0 KB)

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

octoprint version 1.8.1, Ender 3 with skr mini e3 v3, custom firmware, linux

serial.log (4.6 KB)

Where Octoprint hangs at

LSUSB terminal results

DMESG terminal results

Usb-devices terminal results

lsusb -v terminal results
lsusb -v.log (3.2 KB)

Board processor

Hello @Br000gle !

You may have a look on this:

1 Like

Yes, I might not have been very specific on that, but isolating the power is what I meant by data only usb cable. I actually had set the cable that way long ago because I’ve always printed via usb and I didn’t like how the printer screen would stay on even when the printer was powered down, unless I removed the usb cable ):

Your "data only" USB cable has 3 wires, correct (i.e. only the +5v wire is missing)?

1 Like

Yes, I have 3 cables I’ve tried. One without the +5v connected, and one where it’s covered by tape. I also tried a third cable that hasn’t been altered. All 3 produce the same results. Device shows up correctly under lsusb, USB port shows up under octoprint, but connection can’t be established )-:

Take the SD card out of the printer

1 Like

It’s not a creality mainboard :smirk:

Lol no but, same result sadly )-:

Already tried other baudrates?
Even it is the same setting, one never knows...

1 Like

I've tried every baudrate in the dropdown menu within octoprint, but I haven't tried changing the buadrate in the printers firmware. It's set to 115200

You do not need to isolate the 5v USB on the E3V3 board. There is a link on the board that isolates the 5v. You have to bridge the link is you need to supply the board from the USB port

What version of Marlin are you using? Have checked the serial definitions and board rate set in the marlin firmware.


1 Like

You may load a firmware that is known to be good to check the hardware.

1 Like

Originally I was running "Marlin bugfix-2.1.x" from both a precompiled service I pay for and also from a firmware I compiled myself. baudrate is locked to 115200 in both firmwares. As far as serial definitions, I'm not sure what to do there but assume they are set right because the board connects fine in windows, and the same definitions are being used on a creality 4.2.2 board that connects fine both in windows and to octoprint. I just now tried Marlin directly from BTT's github page but am experiencing the same behavior )--:

I just installed Marlin directly from BTT's github page but that is giving me the same results )--: is there any other firmware you know of that I could try? Honestly, my mind is telling me it's the driver being used that is causing the issue but I don't know how to look into something like that on linux

Can you connect to the board using Pronterface?

1 Like

Yes, pronterface and cura will connect just fine under windows, I've even ran a 3 day print via usb that way, which leads me to believe it's the driver being used in linux isn't talking well with this specific board. Creality 4.2.2 board with firmware almost identical (besides hardware related code) is working fine both in windows and in linux to communicate with octoprint.

I just saw, you use portlister.
Have you tried without that plugin. But not just disabled, but uninstalled?
Just a shot in the dark...

1 Like

A shot in the dark might be exactly what I need :') lol

Unfortunately its still giving me the same results though )--:

I'm going to look into reinstalling the driver linux is using for usb communication with the board


(Final solution)

So initially I thought that I had fixed the problem, but the issue came right back after a restart. I found that I had to edit the rules for ACM devices to match the rules for USB devices for it to actually hold. I did so by following this post-

link to post from picture
chmod - Changing permissions on serial port - Ask Ubuntu.

(Previous solution, wasn't persistent upon restart)

So a help page admin on facebook suggested I reinstall the controller drivers from the top. Following the instructions on the page he sent me, issuing commands for the usb COM would lead to the error "no such file or directory"

The command I have underlined in red was where the error was being thrown.

Thinking how the printer COM wasn't even showing up like that, I decided to type it out how it was being shown in octoprint instead, like this

sudo chmod a+rw /dev/ttyACM0

And well what do you know, it's connecting like a champ now with a regular unmodified usb cable with no issues what so ever :'---)

So I guess the error wasn't exactly the driver, but actually an issue with the device not having sufficient permissions within the system

Thank you all for all the leads and hopefully this post can help anyone else struggling with this issue as I've seen a few posts floating around

Have a good day everyone and happy printing! :---)

1 Like

Now I just need to figure out how to get this command to run on startup since the permission seems to reset on startup after a restart, which shouldn't be very difficult :--)