Configurable timeout

[EmJay276]

Make trsync_timeout and trsync_single_mcu_timeout configurable

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.

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, ...

[Sineos]

As mentioned in the thread you referred to, I would caution against applying this temporary solution as it may only address certain uncommon scenarios without resolving the underlying problem. Users who use this "fix" carelessly could encounter issues that are incredibly difficult to diagnose.

[EmJay276]

As mentioned in the thread you referred to, I would caution against applying this temporary solution as it may only address certain uncommon scenarios without resolving the underlying problem. Users who use this "fix" carelessly could encounter issues that are incredibly difficult to diagnose.

I am aware of the issues caused by longer timeouts, but should the user not be able to set this in the config instead of the python code? The option already exists, why not make it able to be configurable and therefore also show up in the log?

I think in my case it has something todo with the USB -> CAN adapter, cause USB is sometime bussy and therefore the CAN message will timeout.

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[EmJay276]

It would be great if anyone can review it or add comments in the forum https://klipper.discourse.group/t/configurable-timeout/12032

[silence48]

Was this included in 0.12

[Sineos]

No and likely will never be as it is not considered a fix but a bandaid that might lead to more undesirable behavior.

Please continue on discourse (above link) if you feel the need to discuss.