Mainline Klipper and error "ls: cannot access '/dev/serial/by-id/"

I have followed the instructions at Rappetor/Sovol-SV08-Mainline several times from scratch and I am unable to get the mcu and extra_mcu to be recognized by the BTT-CB1. I have re-flashed the backup .bin files (toolhead_original_firmware.bin and mainboard_original_firmware.bin) and they are detected and the printer has functionality as per end of STEP 5. My katapult.bin file is 5K. My settings in make menuconfig are identical to Step 7. When I try and execute “ls -la /dev/serial/by-id/”, I get the error: " ls: cannot access ‘/dev/serial/by-id/’: No such file or directory". This does not happen when I re-flash the backup .bin files.

Any thoughts on a way around this?

Does anyone have a working katapult.bin file to share?
The chip on my Sovol SV08 board is confirmed to be an STM32F103VET written on the chip.

Any help appreciated…

Thanks
Marty

I try and execute “ls -la /dev/serial/by-id/”, I get the error: " ls: cannot access ‘/dev/serial/by-id/’: No such file or directory". This does not happen when I re-flash the backup .bin files.

Are you sure to well undestood the step 7.7 (Full chip erase) ? This trouble look like related to that. The katapult firmware does not look like properly installed.

Hi @mistral … thanks for response. I have done full chip erase and have reinstalled the backup firmware successfully back and forth many, many, times. The backup firmware works and can be seen by the raspberry pi. I have erased the chip every time without issue. The Cube programmer also confirms a successful erasure. Do you have a katapult.bin file you could share to test? Any other thoughts?

I don’t know the consequences if you install a firmware who are not built with your own main board. If that was a valid option I trust that they offered this option in the guidelines.

So currently you didn’t break your printer… do not try random option, with bad firmware that is totally possible to break it (or at least some part of the printer).

Ps: and I can’t guest what is the trouble but maybe someone else will answer later. The sovol klipper is not very outdated currently and the klipper mainline will probably improve the guidelines with time.

Hello,
I don’t have a Sovol SV08.
I have also had this error with other 3D printers with custom firmware.
You can try accessing /dev/ttyS0 directly in the printer.cfg

[mcu]
serial: /dev/ttyS0
restart_method: command

Thanks @sixer, I will explore that direction. My problem, however, stems from the fact that the two mcu’s are just not “seen” by the host. “sudo dmesg” has these errors in it.

[ 5.330957] usb 6-1: device not accepting address 4, error -62
[ 5.398866] usb 5-1: new full-speed USB device number 5 using ohci-platform
[ 5.530873] usb 6-1: new full-speed USB device number 5 using ohci-platform
[ 5.822900] usb 5-1: device not accepting address 5, error -62
[ 5.828897] usb usb5-port1: unable to enumerate USB device
[ 5.954886] usb 6-1: device not accepting address 5, error -62
[ 5.960891] usb usb6-port1: unable to enumerate USB device

Hello @TheMarty,

I just went through the process of installing mainline klipper yesterday and everything worked for me. There seem to be some commands that you need to run as superuser “sudo”, and I have noticed not doing so may lead to problems when the user space calls kernel space devices!

This seems to be a linux issue with whats connected to the USB ports. Maybe looking at this may help unable to enumerate USB device : USB - Ask Ubuntu

Hope this can help you get closer.

Hi @sambhanji ,

Thanks… I’ll have a look. I did manage to get mainline installed. Rappetor sent me his compiled bin file for Katapult and then everything else moved along perfectly. I will have a look at your link as I’ve had this same issue on other projects in the past.

M

2 Likes

Hi i was wonder if you could possibly send me the katapult.bin files im having the same issue

Try it here…look for the katapult.zip file to download.

Awsome thankyou ill give it a go

It seems that udev, which is responsible for populating the /dev device tree, may not be running. Possibly due to some error which prevents it from starting. Try this:
As root, execute /etc/init.d/udev restart
see whether any errors are reported.

see whether it has been loaded:
ps aux | grep udev
a line ending in “/lib/systemd/systemd-udevd” should show.

systemctl status systemd-udevd
should give more information about udev running.

The line with “Active:” would be most relevant in this context, and maybe the bottom lines, should they contain something out of the norm.