SKR Mini E3 V3 not connecting to octoprint

[5ft24]

Take the SD card out of the printer

[Br000gle]

It’s not a creality mainboard

Lol no but, same result sadly )-:

[Ewald_Ikemann]

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

[Br000gle]

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

[Bill.b1]

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.

Bill

[Ewald_Ikemann]

@Br000gle

custom firmware

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

[Br000gle]

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 2.0.9.3 directly from BTT's github page but am experiencing the same behavior )--:

[Br000gle]

I just installed Marlin 2.0.9.3 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

[Ewald_Ikemann]

Can you connect to the board using Pronterface?

[Br000gle]

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.

[Ewald_Ikemann]

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

[Br000gle]

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

[Br000gle]

SOLUTION FOUND!

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

[Br000gle]

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

[Br000gle]

^update, it is in fact very difficult lol...

[Br000gle]

Okay, found final solution. Will update solution answer

[Ewald_Ikemann]

Hard work, but worth the effort

[Br000gle]

110% worth the effort! plus my ocd won't let me let anything go lol. This solution was also probably very basic linux stuff but since I've let go of regular linux usage about 10 years ago, it's all a foreign language to me lol. Happy to have it going though! thanks for the suggestions btw :--)

[cmcm]

EDIT: SOLVED - reinstalling Octoprint fixed my issue below. No clue why.

---

I am having the same issue, but the main difference is that I started out with ch34x drivers and they still didn't facilitate a successful connection. I even removed them as if they were the ch341 drivers, and still no changes. Unlike your experience, I was not able to even temporarily make this work.

I am able to confirm a successful connection with a Windows PC connected directly - Cura immediately finds the printer and I can control it as expected. So, this must be something Linux or Octoprint-related.

Also of note, I was using Octoprint for about a month on the Creality 4.2.2 mainboard until I upgraded to the BTT SKR Mini E3 V3 today. All was well with that board.