# Configurable timeout **URL:** \ **Category:** Features\ **Created:** [December 3, 2023, 11:26am UTC](https://klipper.discourse.group/t/configurable-timeout/12032 "2023-12-03T11:26:03Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [December 3, 2023, 11:26am UTC](https://klipper.discourse.group/t/configurable-timeout/12032/1 "2023-12-03T11:26:03Z")
I created a PR to make the timout for single and multi mcu configurable via the config. Why? Some people (including me) have (sometimes) issues with a multi mcu setup with a timeout during z-homing. The default timeout is 25ms, in my case it just don’t workout every time. Increasing the limit to 50ms fixes this issue for me entierly, but needs to be done by modifying the mcu.py file after every klipper update. This PR makes the timeout configurable via the config while keeping the default values as is. I am aware of the issues caused by longer timeouts (any already tried every suggested solution), but the user should be able to set this in the config instead of the python code. Additonally it will then be visible in the log and simplify debugging instead of changing it in the python file. PR > > > Make trsync\_timeout and trsync\_single\_mcu\_timeout configurable > > Some people (i…ncluding me) have (sometimes) issues with a multi mcu setup with a timeout during z-homing. > The default timeout is 25ms, in my case it just don't workout every time. Increasing the limit to 50ms fixes this issue for me entierly, but needs to be done by modifying the mcu.py file after every klipper update. > This PR makes the timeout configurable via the config while keeping the default values as is. > > Signed-off-by: Michael Jäger michael@mjaeger.eu > > PS > Yes I know the massiv thread for fixing can issues, None of the suggestions helped for me, I have no lost or retransmitted packages, ... ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [December 4, 2023, 1:47am UTC](https://klipper.discourse.group/t/configurable-timeout/12032/2 "2023-12-04T01:47:52Z")
This setting has the potential to cause a serious head crash that could damage a printer, so I personally don’t think it should be user facing. I especially don’t think it should be adjustable without an upper bound on the value. Perhaps the default is too strict, but I have personally never experienced this issue on either of my printers where I’ve used a variety of CAN boards (Huvud 0.5, Huvud 0.61, EBB42, Fly SHT42, and SB2040). ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [December 4, 2023, 2:05am UTC](https://klipper.discourse.group/t/configurable-timeout/12032/3 "2023-12-04T02:05:11Z")
If you are having issues with the default 25ms, then I think it would be good to post the Klipper log files here from sessions containing the error (from code running the pristine Kipper code). The system should be able to reliably respond within 25ms, and if it isn’t there is a low-level reason for that inability. If at all possible I think we want to track down the root cause of the issue instead of adding config options to ignore a real problem. -Kevin ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [December 5, 2023, 11:36pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/4 "2023-12-05T23:36:07Z")
@koconnor Thank you very much for you help 🙂 I will try to reproduce the problem and post the logs. To get additonal information, I need to emergency stop after the timeout occures, correct? ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [December 7, 2023, 5:08pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/5 "2023-12-07T17:08:30Z")
Yes, for best results, issue an `M112` command (or hit the emergency stop button) immediately after the undesirable event. -Kevin ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [December 19, 2023, 9:58am UTC](https://klipper.discourse.group/t/configurable-timeout/12032/6 "2023-12-19T09:58:22Z")
Haven’t got any time yet to create the logs. But I found this recommendation in the Voron discord to adjust the timeout to 50ms für all Happy Hare Users with a can board. > **[Discord - A New Way to Chat with Friends & Communities](https://discord.com/channels/460117602945990666/909743915475816458/1185468365930770523)** > > Discord is the easiest way to communicate over voice, video, and text. Chat, hang out, and stay close with your friends and communities. ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [January 2, 2024, 12:59am UTC](https://klipper.discourse.group/t/configurable-timeout/12032/7 "2024-01-02T00:59:50Z")
@koconnor Here are the logs, I could reproduce it with 25ms timeout. If you have some spare time to have a look at it, it would be great! Appreciating your help. I used by branch, but there is virtually no difference to the main branch when using 25ms timeout. There are no `bytes_retransmit` or `bytes_invalid`, klipper is also pinned to one core of the CPU which reduced this issue significantly. [klippy.log](https://klipper.discourse.group/uploads/short-url/qE0tMJHXqJqqrhSMldIMWUT9nW9.log) (349.4 KB) [moonraker.log](https://klipper.discourse.group/uploads/short-url/2rNKWprWq7iWZj7LcwacxXDdjGv.log) (21.9 KB) ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [January 2, 2024, 3:01am UTC](https://klipper.discourse.group/t/configurable-timeout/12032/8 "2024-01-02T03:01:05Z")
It looks like you’re running an old version of Klipper in “usb to canbus bridge mode” that is known to have problems ( [Upgrade if using Klipper USB to CANbus bridge mode](https://klipper.discourse.group/t/upgrade-if-using-klipper-usb-to-canbus-bridge-mode/10968) ). You should definitely update, as we know there were issues with older versions of the code. If the issue does reoccur after updating, I really need the logs from a pristine version of Klipper in order to investigate. Issues like this are very hard to track down, and they’re basically impossible if I don’t have the exact code that is running. -Kevin ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [January 2, 2024, 5:13pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/9 "2024-01-02T17:13:32Z")
@koconnor Here are the logs for the new Version: v0.12.0-58-g25bc649c Everything was flashed to the new firmware ![grafik](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/2/2168af7f06480e7b7d9978ef9c05d169b27f1187.png) The test I was running: Z homing and moving up in a loop. But I didn’t even get 2 or 3 homes till the `Communication timeout during homing z` kicked in. ```auto G28 G1 F3000 Z200 G28 Z G1 F3000 Z200 G28 Z G1 F3000 Z200 G28 Z G1 F3000 Z200 ... ``` [klippy.log](https://klipper.discourse.group/uploads/short-url/xoIM9yzXC4t6Q8LcIBRxewfU4c1.log) (395.6 KB) [moonraker.log](https://klipper.discourse.group/uploads/short-url/g19OmrLLTGCXQWDTPKpIDIlGL6m.log) (11.1 KB) ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [January 2, 2024, 6:42pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/10 "2024-01-02T18:42:59Z")
Alas, the log does not contain all the messages being sent at the time of the event. The time between the event and the shutdown request was too long. Also, the Klipper code was modified with gcode\_shell\_command.py code. Best to reproduce with the pristine Klipper code. You can try modifying Klipper to raise a shutdown event immediately after a timeout event - that can make it easier to ensure the log is complete: ```diff --- a/klippy/extras/homing.py +++ b/klippy/extras/homing.py @@ -135,6 +135,7 @@ class HomingMove: if error is None: error = str(e) if error is not None: + self.printer.invoke_shutdown("Forcing shutdown for homing debug") raise self.printer.command_error(error) return trigpos def check_no_movement(self): ``` If modifying the code, be sure to run a full `sudo service klipper restart` after making any changes. Also, if you are able to reproduce, it would help if you could provide the canbus log from the event as described at [CANBUS Troubleshooting - Klipper documentation](https://www.klipper3d.org/CANBUS_Troubleshooting.html#obtaining-candump-logs) . Just compress the resulting log file and attach it here. Finally, there is a spike in system load just a few seconds before the timeout is reported (without a spike in klipper processing load - which indicates it is external from klipper): ![sysload](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/6/6a343d94ba90dd8e7d48903ac398fdfd8b39358d.png) (note the spike of the cyan line near the right side of the graph). If you’ve got any kind of background processes (webcams, timelapse software, remote monitoring, etc.) then you may want to check if the problem persists with them disabled. -Kevin ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [January 2, 2024, 7:58pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/11 "2024-01-02T19:58:52Z")
Thank you for your very fast response! - The load peak was due to opening up the webcam view, but I also have the issue with deactivated webcam (deactivated in moonraker but still physically connected). - The gcode\_shell\_command.py is only used for config backups being pushed to github, see [here](https://github.com/dw-0/kiauh/wiki/How-to-autocommit-config-changes-to-github%3F), this should not have any effect on the homing. This time it went straight into the homing error not even having moved 20mm down, everything should now be contained in the logs. You find all files (including the candump) attached. [klippy.zip](https://klipper.discourse.group/uploads/short-url/9vCdx1UGTQkherfgqvpbq9ctrTx.zip) (118.4 KB) ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [January 2, 2024, 10:24pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/12 "2024-01-02T22:24:24Z")
I also removed the webcam config from crowsnest, so the webcam should also no longer be active (I think). Now the system load is less than 10% when the timeout occures. I also found the docu for the graphs 😉 ![loadgraph_s](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/5/51d9c7f5f6a5a9fb4fee0f995479498a86beebb1.png) ![loadgraph](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/c/ca47922dfec7b134ccefd755942c6de86780f3be.png) [klippy.zip](https://klipper.discourse.group/uploads/short-url/9BKgBcgUoJAxo3gK4Pa71HaoBaf.zip) (637.0 KB) ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [January 3, 2024, 12:35am UTC](https://klipper.discourse.group/t/configurable-timeout/12032/13 "2024-01-03T00:35:23Z")
The root cause of the error in your log appears to be a communication hiccup of at least 15ms in the USB system (either USB hardware, Linux kernel handling, or Klipper’s CANBUS bridge). Specifically, the main mcu attempted to send a message to the host and the Linux kernel doesn’t report receiving it until 15ms has elapsed. Specifically, this can be seen in the log (after processing with logextract.py): `Receive: 86 850.286296 850.263383 14: seq: 1f(1102), trsync_state oid=13 can_trigger=1 trigger_reason=0 clock=1580327894(850.271477)` The mcu sent the message at `850.271477` but it was not received at the host until `850.286296`. It’s unclear what caused the issue at the (likely) USB level. However, it’s not ideal that Klipper raised a communication timeout due to 15ms of latency. (The goal is to avoid 25ms of latency.) I think some scheduling improvements within Klipper could, in practice, reduce the chance of a timeout. Could you try the code at [GitHub - KevinOConnor/klipper-dev at work-trsync-20240102](https://github.com/KevinOConnor/klipper-dev/tree/work-trsync-20240102) ? (Be sure to issue `sudo service klipper restart` after making the change.) -Kevin ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [January 3, 2024, 1:30pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/14 "2024-01-03T13:30:15Z")
I just tested [work-trsync-20240102](https://github.com/KevinOConnor/klipper-dev/tree/work-trsync-20240102) several times: - 01: after `sudo service klipper restart` - 02: after timeout at 01 and firmware restart ← took almost 10 min of homing to get the timeout, but I forgot to activate candump - 03: after removing the klipper.service pinned to just 1 core of the CPU (full reboot of the system) `CPUAffinity=3` in `/etc/systemd/system/klipper.service` - 04: after timeout at 03 and firmware restart 01: ![loadgraph_s](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/5/52a9e43c57f5856443977ee596b871d1d747a326.png) 02: ![loadgraph_s](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/e/eb6d0915fde82ae8911923cbe0ecd36cae68eaf2.png) 03: ![loadgraph_s](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/5/52495c31e9f7298e98015b14b7abec0ac435c34f.png) 04: ![loadgraph_s](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/5/5fdcca65aae08c08e695ab39d478fdaab6b80166.png) [klipper\_dev.zip](https://klipper.discourse.group/uploads/short-url/siQonaXFsMI4WA0TUy4U3RHorLM.zip) (1.1 MB) ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [January 3, 2024, 2:10pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/15 "2024-01-03T14:10:55Z")
- 05: I was just able to home for 25min without candump and without a timeout. - 06: Enabling the webcam again I got a timeout. 05: ![loadgraph_s](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/5/56f0f9b6a3e107464737949b6f1bd35391593210.png) 06: ![loadgraph_s](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/0/04dec6f89c1854cba72f65af4db95ed3e1fd6e71.png) [klipper\_logs\_05-06.zip](https://klipper.discourse.group/uploads/short-url/cB3bY9f3Ctp3lzCpZgoFyhr59RY.zip) (465.3 KB) ---
**Author:** ![emjay276](https://avatars.discourse-cdn.com/v4/letter/e/5f8ce5/32.png) [@emjay276](https://klipper.discourse.group/u/emjay276)\ **Post date:** [January 3, 2024, 2:25pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/16 "2024-01-03T14:25:34Z")
Just for completeness, my setup: - [MKS SKIPR](https://github.com/makerbase-mks/MKS-SKIPR) - [Mellow Fly SB2040v2](https://github.com/Mellow-3D/Fly-SB2040) - SKIPR: USB 3.0 → USB Hub → Webcam | WiFi Stick | Touchscreen - SKIPR: USB 2.0 → MCU USB Host (CAN via USB bridge), I can’t use the internal (PCB) connection for CAN via UART if I wan’t to use the CAN out of the mcu. Thats something klipper doesn’t support currently as far as I know / [understand](https://klipper.discourse.group/t/mks-skipr-can-bus/5377). - SKIPR: CAN → SB2040 v2 ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [January 4, 2024, 6:48pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/17 "2024-01-04T18:48:18Z")
Okay, thanks for testing. Can you summarize your results? Is the code on that development branch an improvement, the same, or worse? Have you been able to identify a pattern that leads to an increase in timeouts? Can you pull that development branch again (now at commit a493fe7f) and see if that improves behavior? FYI, all of the logs I’ve seen so far indicate the same basic behavior - sporadic latency of 15+ms at the (likely) USB interface. This is in contrast to your connection’s normal latency of ~1ms. FWIW, this does seem to be a hardware problem (or system driver problem). -Kevin ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [January 4, 2024, 7:06pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/18 "2024-01-04T19:06:19Z")
Also, have you tried hooking up the “SKIPR” board to the usb hub? A USB3 hub may actually improve scheduling (many hubs can off-load processing from the host). -Kevin ---
**Author:** ![firecop97](https://avatars.discourse-cdn.com/v4/letter/f/f9ae1b/32.png) [@firecop97](https://klipper.discourse.group/u/firecop97)\ **Post date:** [January 9, 2024, 6:20pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/19 "2024-01-09T18:20:30Z")
@koconnor I have Octopus V1.1 with BTT U2C and BTT SC2209 can bus. I’m getting the Communication time out during probe error. I can limit the error by increasing my timing from .25 to .50 but i know that isn’t a fix. I did try something else you suggested in some of your documentation by changing two lines but that didn’t work because it didn’t like it and i had to update/ installed klipper again to get things running again. If i reboot my pi I will still get the error but if i power off the whole printer i will get get a few prints fine until the error appears again. I have done a lot of research but everyones setup is different. Where can I go from here. Thank you for any direction. I’m trying to learn more with this also not just make it work, [klippy (20).log](https://klipper.discourse.group/uploads/short-url/wnbFjYS01KzAkWj6CB9IptyE2uA.log) (4.0 MB) ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [January 9, 2024, 11:57pm UTC](https://klipper.discourse.group/t/configurable-timeout/12032/20 "2024-01-09T23:57:49Z")
If you want to try the development branch, you’d need to ssh into the host machine and switch to that branch - typically with something like: `sudo service klipper stop ; cd ~/klipper ; git fetch https://github.com/KevinOConnor/klipper-dev.git work-trsync-20240102 ; git checkout work-trsync-20240102 ; sudo service klipper restart` If you are still having problems after changing to that branch, you should remove any local changes (no z\_calibrate.py modification), and be sure to run an `M112` command immediately after the timeout event occurs. Then attach the resulting log file here. -Kevin [Next page](https://klipper.discourse.group/t/configurable-timeout/12032.md?page=2)