No USB connection after printer restart #77
Comments
|
This is happening to me as well. Just coincidentally I had duct-taped the 5v line of the USB connector and though it was related, but looks like its not. Perhaps this is a Klipper issue and not a prind one. Edited: I do not see any open ticket in Klipper related to this. |
|
This is usually the case when the serial device changes after a printer reset (e.g. from ttyACM0 to ttyACM1) and can be mitigated by running klipper in privileged mode via your services:
klipper:
privileged: trueIf that does not fix your issue, please run |
|
The device does not seem to change. I don't need to update the entry (/dev/ttyUSB0). Also privileged mode does not help
|
|
Okay if i set the device up as ttyUSB* it changes after a reconnect. Also privileged does not change anything. |
|
Okay, so it would probably be best to also mount
services:
klipper:
privileged: true
volumes:
- /dev:/dev
- ./config:/opt/printer_data/config
- run:/opt/printer_data/run
- gcode:/opt/printer_data/gcodes
- log:/opt/printer_data/logs
If it still does not work, run the get-info script again and upload the generated tar archive, not just the scripts output. I just tested this on my machine and could successfully reconnect after the board was reset. |
This - sir - works like a charm :) |
|
With the merge of #78 this is now in main. |
|
@mkuf is it sensible to allow docker run in privilege mode? If i understand correctly, this is basically giving it root access. |
|
Running a Container in privileged mode grants access to the hosts devices, it does not grant root access to the host. Klippy is still run by an unprivileged user within the container, just as if it was installed directly on the host. See the docker docs for reference: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities As klipper is hardware (=device) dependent it makes sense to run it in privileged mode. From a usability standpoint this is a great improvement, as Users only have to set their serial device in the printer.cfg and are not forced to interact with compose files. |
|
Using this mode will render obsolete the rule for defining the group of the dev for those hosts not based on Debian? |
|
As klipper is still run by an unprivileged user within the container, it is still necessary to have the right permissions for the device it is trying to access. So the udev rule for matching the group access to the device is required if groupids do not match between the host an the klipper container, as described in the readme. Lines 144 to 156 in 21f9b51 |
|
Im still having the issue. I added volumes in the override config file, do i need to add all the sections of Klipper in that file, thus including the privilege or it picks it up from the original docker compose? @mkuf |
|
Please run |
|
@mkuf |
|
BTW, the printer is currently turned off. |
|
There is not much sense in trying to troubleshoot the issue if the printer is turned off 😄 From the klippy log, /dev/ttyUSB0 is missing. That makes sense, when the printer is turned off. You'll have to use the symlink provided by klipper under
|
|
Any update @GAZ082? |
|
@mkuf As you said, the issue here is the host not re-creating the dev upon printer restart. Dont know why, perhaps the fact that I duct-taped the 5v line in the USB plug has something to do. But its not related to prind. |
Hi,
when my printer is turned on again klipper is not able to connect anymore. I have to restart the whole system to be able to connect again.
Also after a restart i have to take down the stack and start it again. The container klipper-klipper-1 is not started and i am not able to connect when i start it manually.
System: Raspbi 4
Connection via USB
Printer: Neptune 3 Pro
Greetings
The text was updated successfully, but these errors were encountered: