Improved MCU connection error messages

[3DCoded]

Discussion at https://klipper.discourse.group/t/improved-mcu-connection-error-messages/23174?u=3dcoded

This PR aims to make it easier for users (especially new users) to diagnose MCU connection issues without looking into the klippy.log. It also speeds up the display of the error messages from the default 90s (detail in each error).

MCU: Unable to Connect

This error has been updated to add two additional (very common) cases. These take about 8s to appear.

Serial port not found

Serial port in use by another MCU/program

Serial connection closed / Timeout on connect / Wait for identify_response

Thank you @Sineos for directing me to this common error.

Updated version (12s to appear):

Lost communication with MCU

Updated to recommend the user to check their USB/CAN connection.

[KevinOConnor]

Thanks for working on this. What is the status of this PR - are you looking for a review or is still under discussion?

-Kevin

[3DCoded]

Hi @KevinOConnor ,

I'd say this PR is ready for review. The most recent changes were made to comply with the linter.

[3DCoded]

if '[Errno 2] No such file or directory:' in str(e): is not the right way to check for a specific error in python (thank god), please use the proper FileNotFoundError exception check.

It looks like the type of error thrown is a SerialException, not a FileNotFoundError, but thank you for the tip. I switched to use e.errno instead of parsing str(e).

[thijstriemstra]

python contains constants for these error nrs, eg errno.ENOENT

[3DCoded]

python contains constants for these error nrs, eg errno.ENOENT

Thank you. I've updated the code to use errno.ENOENT and errno.EAGAIN instead of arbitrary integers.

[KevinOConnor]

Thanks for working on this. As high-level feedback, I'm concerned these revised error messages could cause confusion.

The revised messages seem to target "USB/CAN" connections, but these errors could occur on any of Klipper's communication systems - direct UART connections, linux mcu pipe connections, etc. . So, for example, if the "linux mcu" failed and users were directed to check their USB/CAN connections it could result in a lot of lost time.

For what it is worth, on a "philosophical level" I think we want the low-level code to check for errors and report what occurred. I don't think that code should try to guess why it went wrong or to guess how one can fix it. The fear is that the low-level code doesn't have enough information to provide good guesses and it adds code complexity to an area of the low-level code that often already has high complexity.

Thinking out loud, the klippy/extras/error_mcu.py module was built to analyze errors and provide insights into causes. Perhaps that module could be extended to provide more context to these types of low-level errors.

Thanks again, -Kevin

[3DCoded]

The revised messages seem to target "USB/CAN" connections, but these errors could occur on any of Klipper's communication systems - direct UART connections, linux mcu pipe connections, etc. . So, for example, if the "linux mcu" failed and users were directed to check their USB/CAN connections it could result in a lot of lost time.

I can revise the error messages to address general MCU connections, not USB/CAN specific.

Thinking out loud, the klippy/extras/error_mcu.py module was built to analyze errors and provide insights into causes. Perhaps that module could be extended to provide more context to these types of low-level errors.

Thanks for the tip. I can look into that.

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