Auto-reconnect

[Avalonnw]

I might be the only one, but I sometimes turn my printer off.
(Sorry, could not resist putting a full stop there).
As I run OP and Klipper on a laptop, I don't turn THAT part off, so it's only the printer itself. What would be nice, if Klipper host could ping MCU every once in a while and auto-reconnect when the printer is back on. Currently I have to restart service to get connection.

[FHeilmann]

did you try 'RESTART' and 'FIRMWARE_RESTART' in your host software on your laptop?

[Avalonnw]

Restart works, but that's whan I want to avoid

[FHeilmann]

I don't mean restarting the service (which I assume you mean the sudo service klipper restart)
Simply issue a 'FIRMWARE_RESTART' or 'RESTART' command in your octoprint terminal to restart klipper and reconnect to your board.

[Avalonnw]

Yes. Sorry, I was not clear. Those are the commands I normally use.

[FHeilmann]

The issue I see with that is that klipper cannot know whether the mcu was shutdown on purpose or just crashed. In case of a faulty MCU your suggestion would send klipper into a constant bootloop. Octoprint also doesn't automatically reconnect to a serial port that comes back online so I think this is how it is supposed to be.

[Avalonnw]

If nothing wrong with service com port stays connected even if mcu is off.
Even if there is a problem with mcu, bootloop of 5s or so won't a problem. Also you can just restart service if something is wrong.

[JustAnother1]

Just for information / background:
A solution for the bootloop could be that Klipper counts the reboots. After 3 failed firmware restarts Klipper could stop. On new communication requests or after some time the loop could be restarted (try to communicate, if this fails reset firmware,..) Approaches like this are used in high availability software.
I think Octoprint has some auto connect feature. If not then that would be an Octoprint issue (that they might or might not want to fix)
Then all over Klipper the strategy is to fail on all errors (timer misses,..) so this continue in a failure situation is against the Klipper strategy. The reason for that strategy is to not cover up issues in the printer / electronics / firmware.
Therefore the automatic firmware reset feature is not compatible with the Klipper strategy.

[Avalonnw]

Why can't it raise the flag that something is wrong?
And, I'm not saying it should do auto-firmware reset, just sort of a ping for MCU every few seconds.
Also, you'd notice that virtual serial port that Octoprint uses to connect to Klipper has nothing to do with actual Klipper-MCU connection and it stays open even if MCU is off (because Klipper service is running still).

[KevinOConnor]

Auto reconnect has been raised a few times (eg, #729 , #478 ). The fundamental issue is that the outage could have been the result of a severe error and reconnecting in that situation could make the problem worse. I feel the user should acknowledge the error (via a RESTART or similar command) prior to the software resuming normal operation.

-Kevin

[sidddy]

@Avalonnw I'm also one of the few people that actually switch off their printer, but keep Klipper running. I solved the "manual Klippy restart" problem by adding a udev rule to the linux environment which runs klippy. I created a new udev rule /etc/udev/rules.d/98-klipper.rules with the content:

## rule to restart klipper when the printer is connected via usb
SUBSYSTEM=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ACTION=="add", RUN+="/bin/sh -c '/bin/echo RESTART > /tmp/printer'"

And now klippy gets a RESTART command sent whenever I connect or power on my printer. This only happens when the USB device is added to the system and not when Klippy automatically disconnects due to an error situation. Therefore the risk which Kevin mentioned above should be avoided.
Note that you'd have to change the product-id and vendor-id in above rule according to your setup (can be figured out via lsusb)

[Avalonnw]

Oh WOW! Thanks, I'll try that!

…

On Fri, 23 Nov. 2018, 19:08 sidddy ***@***.*** wrote: @Avalonnw <https://github.com/Avalonnw> I'm also one of the few people that actually switch off their printer, but keep Klipper running. I solved the "manual Klippy restart" problem by adding a udev rule to the linux environment which runs klippy. I created a new udev rule /etc/udev/rules.d/98-klipper.rules with the content: ## rule to restart klipper when the printer is connected via usb SUBSYSTEM=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ACTION=="add", RUN+="/bin/sh -c '/bin/echo RESTART > /tmp/printer'" And now klippy gets a RESTART command sent whenever I connect or power on my printer. This only happens when the USB device is added to the system and not when Klippy automatically disconnects due to an error situation. Therefore the risk which Kevin mentioned above should be avoided. Note that you'd have to change the product-id and vendor-id in above rule according to your setup (can be figured out via lsusb) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#835 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG6h0Xu8QtPSgNzAm-x2BfVaE5kNH0FNks5ux7r7gaJpZM4YA5SY> .

[drzejkopf]

@sidddy That's awesome, it works flawlessly, I test it for more than one week now, I have tried powering printer off, quickly unplugging and plugging printer during test print, and it was always giving error (it was first time I was happy when getting error :D)

[Lissanro]

@Siddly Perfect solution. I was googling how to get Klipper to restart automatically when I either turn my printer off and on or after manually pressing reset and this worked perfectly. Now reset button on my printer actually works as expected with this udev rule. Manually sending RESTART command or restarting the host in addition to my printer is too inconvenient and is not necessary especially if all I did is turned my printer off and on. I think turning my printer off and on (or manually pressing reset button) should not count as an error - this is normal thing to do with any printer. Thank you very much for sharing your solution.

[teikjoon]

I couldn't get the udev rule to work, because on my Linux system (armbian) /tmp had the 't' flag - and /tmp/printer couldn't be accessed by root - it would give me the error 'failed with exit code 2'

Fixed this by changing the command that the udev rule runs, using sudo to run as the Klipper user :

## rule to restart klipper when the printer is connected via usb
SUBSYSTEM=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ACTION=="add", RUN+="/usr/bin/sudo -u <username> /bin/sh -c '/bin/echo RESTART > /tmp/printer'"

where <username> is the user that starts Klipper

[dw-0]

The udev rule mentioned by @sidddy doesn't work for me.
I changed the command within the string from
/bin/echo RESTART > /tmp/printer
to
/bin/echo RESTART > /dev/pts/0
and that fixed it for me.

I don't have a clue WHY this is working only this way, since printer is basically only a symlink to /dev/pts/0. So it should work both ways...but it doesn't.

Btw both /bin/echo RESTART > /tmp/printer and /bin/echo RESTART > /dev/pts/0 work just fine when entering directly through a terminal when connected via ssh to the pi.

[maartenvang]

The udev rule mentioned by @sidddy doesn't work for me.
I changed the command within the string from
/bin/echo RESTART > /tmp/printer
to
/bin/echo RESTART > /dev/pts/0
and that fixed it for me.

I don't have a clue WHY this is working only this way, since printer is basically only a symlink to /dev/pts/0. So it should work both ways...but it doesn't.

Btw both /bin/echo RESTART > /tmp/printer and /bin/echo RESTART > /dev/pts/0 work just fine when entering directly through a terminal when connected via ssh to the pi.

Good call. For me /tmp/printer is a symlink to /dev/pts/1 instead, that works for me.

[whoim2]

Hey. Im connected via /dev/serial0 to board. Im use relay module and octoprint PSU plugin for power control. After power on im need use firmware_restart from terminal. Use firmware restart "before connect to printer" in "gcode scripts" no work. Any ideas?)

[dw-0]

@whoim2 did you even try the solutions given in this thread?

[EagleeyeKai]

It does not work for me either. I created the file 98-klipper.rules in /etc/udev/rules.d/

## rule to restart klipper when the printer is connected via usb SUBSYSTEM=="usb", ATTRS{idVendor}=="abcd", ATTRS{idProduct}=="2341", ACTION=="add", RUN+="/usr/bin/sudo -u pi '/bin/echo RESTART > /tmp/printer'"

lsusb shows the following

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 2341:abcd Arduino SA
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Do I need to change any file permissions to 98-klipper.rules?

I also tried to replace /tmp/printer with /dev/pts/0

From the terminal "/bin/echo RESTART > /tmp/printer" works just fine.

[teikjoon]

@EagleeyeKai what does the output of 'ls -al /tmp/' show? Specifically the /tmp/printer symlink.

Am curious about this too.

[EagleeyeKai]

@teikjoon Thanks for helping me out!

lrwxrwxrwx 1 pi pi 10 May 12 14:34 printer -> /dev/pts/0

[teikjoon]

@EagleeyeKai These are the permissions for my udev rule -

-rw-r--r-- 1 root root 352 May 13 11:58 98-klipper.rules

Since you can restart klipper using terminal, I can only think of two things, the rule not triggering, or the root user not having permission to /tmp/printer (which was my problem - due to /tmp having sticky bit set - thus needing the sudo command prefixed)

Try changing the udev command to this -

SUBSYSTEM=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="abcd", ACTION=="add", RUN+="/usr/bin/logger udev rule triggered"

Then you will need to reload udev rules using sudo udevadm control --reload-rules

After udev is reloaded, try power cycling the printer, if the rule triggers, your /var/log/syslog should have this following lines (specifically the last line, which shows the the rule is actually run) -

May 13 11:59:29 localhost kernel: [3643196.427142] usb 8-1: USB disconnect, device number 2
May 13 11:59:29 localhost kernel: [3643196.428296] cp210x ttyUSB0: failed set request 0x12 status: -19
May 13 11:59:29 localhost kernel: [3643196.434534] cp210x ttyUSB0: failed set request 0x0 status: -19
May 13 11:59:29 localhost kernel: [3643196.441064] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
May 13 11:59:29 localhost kernel: [3643196.441156] cp210x 8-1:1.0: device disconnected
May 13 11:59:40 localhost kernel: [3643207.679468] usb 8-1: new full-speed USB device number 3 using ohci-platform
May 13 11:59:41 localhost kernel: [3643207.908523] usb 8-1: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
May 13 11:59:41 localhost kernel: [3643207.908543] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 13 11:59:41 localhost kernel: [3643207.908554] usb 8-1: Product: CP2102 USB to UART Bridge Controller
May 13 11:59:41 localhost kernel: [3643207.908564] usb 8-1: Manufacturer: Silicon Labs
May 13 11:59:41 localhost kernel: [3643207.908573] usb 8-1: SerialNumber: 0001
May 13 11:59:41 localhost kernel: [3643207.912970] cp210x 8-1:1.0: cp210x converter detected
May 13 11:59:41 localhost kernel: [3643207.923812] usb 8-1: cp210x converter now attached to ttyUSB1
May 13 11:59:41 localhost root: udev rule triggered

[EagleeyeKai]

@teikjoon Is just checked the permissions. I got the same permissions like you have
-rw-r--r-- 1 root root 211 May 12 14:43 98-klipper.rules

I changed the rule according to your proposal, cycled power of the printer. Syslog shows:

`
May 13 18:43:38 octopi kernel: [101321.146982] usb 1-1.3: USB disconnect, device number 6
May 13 18:43:49 octopi kernel: [101331.913532] usb 1-1.3: new full-speed USB device number 7 using xhci_hcd
May 13 18:43:49 octopi kernel: [101332.052755] usb 1-1.3: New USB device found, idVendor=2341, idProduct=abcd, bcdDevice= 1.00

May 13 18:43:49 octopi kernel: [101332.052771] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3

May 13 18:43:49 octopi kernel: [101332.052784] usb 1-1.3: Product: lpc1769
May 13 18:43:49 octopi kernel: [101332.052795] usb 1-1.3: Manufacturer: Klipper
May 13 18:43:49 octopi kernel: [101332.052807] usb 1-1.3: SerialNumber:
May 13 18:43:49 octopi kernel: [101332.057642] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
May 13 18:43:49 octopi mtp-probe: checking bus 1, device 7: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3"

May 13 18:43:49 octopi mtp-probe: bus: 1, device: 7 was not an MTP device
May 13 18:43:49 octopi root: udev rule triggered
May 13 18:43:49 octopi root: udev rule triggered
May 13 18:43:49 octopi root: udev rule triggered
May 13 18:43:49 octopi mtp-probe: checking bus 1, device 7: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3"

May 13 18:43:49 octopi mtp-probe: bus: 1, device: 7 was not an MTP device
`

[teikjoon]

@EagleeyeKai okay cool, from syslog, the udev rule is triggered...now we gotta figure out why the command doesn't restart Klipper...

Do the following -

• change to root user using su root
• execute the command /usr/bin/sudo -u pi '/bin/echo RESTART > /tmp/printer' and see if there is any error message on terminal

[ajain-93]

@EagleeyeKai I had similar issues with trying to get this rule setup on my octopi.

In this reply it looks like you may have switched idVendor and idProduct, idVendor should be 2341.

My issue was that the I was unable to execute the following command: /bin/sh -c '/bin/echo RESTART > /tmp/printer', I was however able to execute /usr/bin/sudo -u pi /bin/sh -c '/bin/echo RESTART > /tmp/printer'. Again, running klipper on octopi.

[EagleeyeKai]

@ajain-93 Thanks for your hint. It corrected this, but still doesnt work

@teikjoon New problem: "su root" askes for a password of the rrot user which I did not net set or change. Of course, I changed the pwd of the user pi However, I do not have a password for the root user...

[EagleeyeKai]

@teikjoon Ok, I changed to the root user using sudo su root..

pi@octopi:~ $ sudo su root
root@octopi:/home/pi# /usr/bin/sudo -u pi '/bin/echo RESTART > /tmp/printer'
sudo: /bin/echo RESTART > /tmp/printer: command not found
root@octopi:/home/pi#

Just to make sure, my 98-klipper.rules file looks like this right now:
## rule to restart klipper when the printer is connected via usb

SUBSYSTEM=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="abcd", ACTION=="add", RUN+="/usr/bin/sudo -u pi '/bin/echo RESTART > /tmp/printer'"

After making changes to the file, I rebooted the system every time. I also tried sudo udevadm control --reload-rulesadditionally.

[teikjoon]

sudo: /bin/echo RESTART > /tmp/printer: command not found

The error message means that the command 'echo' isn't in the /bin/ directory.

Try running whereis echo - it should show you the correct location of the echo command, you can change /bin/echo to this correct location.

[ajain-93]

# /usr/bin/sudo -u pi '/bin/echo RESTART > /tmp/printer'
sudo: /bin/echo RESTART > /tmp/printer: command not found

Try adding a /bin/sh -c in there i.e.:

/usr/bin/sudo -u pi /bin/sh -c '/bin/echo RESTART > /tmp/printer'

My inadequate understanding is that when calling on sudo, RESTART becomes part of the command being run, rather than an argument to echo

[raytrap]

Thank you @siddy for this brilliant idea! I ended up putting this into my rule:
RUN+="/bin/sh -c '/bin/echo RESTART > $(readlink /tmp/printer)'"

[thelastWallE]

I ended up with this:
## rule to restart klipper when the printer is connected via usb SUBSYSTEM=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="abcd", ACTION=="add", RUN+="/usr/bin/sudo -u pi /bin/sh -c '/bin/echo RESTART > /tmp/printer'"
I have the Bigtreetech MINI E3 V1.2

[dilberry]

I couldn't get any of the previous rules to work; I got permission denied (even as root!!) when trying to echo to either /run/klipper/sock (equivalent to /tmp/printer) or /dev/pts/0.

I've worked around this by using udev to restart the klipper.service.

## rule to restart klipper when the printer is connected via usb
SUBSYSTEM=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="614e", ACTION=="add", RUN+="/bin/sh -c '/usr/bin/systemctl restart klipper.service'"

This works for Arch Linux and its klipper package; I'm unsure about OctoPi or Rasbian.

[ph1nt]

Correct file /etc/udev/rules.d/98-klipper.rules

## rule to restart klipper when the printer is connected via usb SUBSYSTEM=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="614e", ACTION=="add", RUN+="/bin/su pi -c '/bin/echo RESTART > /tmp/printer'"

[TheBigBear]

I believe the issue here is the attempt of trying to run as a different user 'su pi -c' system-udevd doesn't like user switching, apparently. ( see https://forum-raspberrypi.de/forum/thread/22708-systemd-service-als-anderer-benutzer-programm-starten/ )

[teikjoon]

I couldn't get any of the previous rules to work; I got permission denied (even as root!!) when trying to echo to either /run/klipper/sock (equivalent to /tmp/printer) or /dev/pts/0.

I've worked around this by using udev to restart the klipper.service.

## rule to restart klipper when the printer is connected via usb
SUBSYSTEM=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="614e", ACTION=="add", RUN+="/bin/sh -c '/usr/bin/systemctl restart klipper.service'"

This works for Arch Linux and its klipper package; I'm unsure about OctoPi or Rasbian.

Thanks for this! I recently replaced my hardware with a Raspberry Pi Zero W, and it works on Raspbian too

[laurienzu]

Can this be the same problem?
Arksine/moonraker#98

[chrstrvs]

Hey!

So I've been trying to get this to work, but like some others, I have so far failed. I think I have tried all of the suggestions in this thread, but none have worked.

When running
/usr/bin/sudo -u pi /bin/sh -c '/bin/echo RESTART > /tmp/printer'
from terminal it works, but when I add this to the rule called /etc/udev/rules.d/98-klipper.rules nothing happens.
SUBSYSTEM=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="abcd", ACTION=="add", RUN+="/usr/bin/sudo -u pi /bin/sh -c '/bin/echo RESTART > /dev/pts/0'"

I tried @teikjoon's suggestions to see if the rule triggers at all, but there is no output in the syslog saying that the rule is running when power cycling the main board, so it seems that my issue is that the rule isn't running at all.
SUBSYSTEM=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="abcd", ACTION=="add", RUN+="/usr/bin/logger udev rule triggered"

I always reload the rules when making changes with
sudo udevadm control --reload-rules
and occationally I reboot Octopi.

Any ideas what to try next?

Regards,
Christian

[teikjoon]

@chrstrvs have you confirmed vendor and productid? what is the output of lsusb

[chrstrvs]

@teikjoon No, I have not. Can you guide me on how to do that?
pi@octopi:~ $ lsusb Bus 001 Device 004: ID 046d:0825 Logitech, Inc. Webcam C270 Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp. Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Now that I think about it, I'm not connecting the Pi and the main board using USB, I'm using the gpio pins on the Pi. That's probably why it won't trigger the rule.
Any ideas on how to change that in the rule?

[teikjoon]

@chrstrvs I don't really have much experience using the GPIO pins, but you should be able to do :

ls -l /dev/serial/by-path/

What's your printer.cfg look like? Do you connect using /dev/ttyAMA0 ?

[chrstrvs]

ls -l /dev/serial/by-path/ returned ls: cannot access '/dev/serial/by-path/': No such file or directory

Yes, I connect using /dev/ttyAMA0.

[lex007112]

Hello, tell me what to spell out in the 98-klipper.rules file if rasberry pi is connected to two printer control boards through two usb ports?