I’m facing an issue with my Klipper setup where the connection to the MCU fails after a restart or reboot. Initially, when the system powers up, everything works perfectly—G-codes run, and the printer functions as expected. However, if I make any changes to printer.cfg or issue a restart command, I first get the error: “Printer is not ready. The klippy host software is attempting to connect.
Please retry in a few moments.”
After a few minutes, it fails with the message: “mcu ‘mcu’: Unable to connect. Once the underlying issue is corrected,
use the ‘FIRMWARE_RESTART’ command to reset the firmware, reload
the config, and restart the host software. Error configuring printer.”
Previously, the connection would automatically re-establish within seconds after a restart, but now it fails completely. I’ve reflashed both the Klipper firmware and the MCU firmware, checked all connections, and ensured that the configuration file is correct. The printer works fine after a complete power cycle, but the issue consistently occurs after a reboot or software restart. Could this be related to a recent Klipper or Mainsail update? Any help in resolving this would be greatly appreciated!
mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_stm32g0b1xx_27000E001950425938323120-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_stm32g0b1xx_27000E001950425938323120-if00'
Your log indicates that your MCU is either:
not correctly connected to the board
not correctly flashed
some host / Linux issues preventing the board to be correctly enumerated as USB device
But if I turn the power off and then turn it back on, the connection is restored. I checked the port using SSH, and it shows up the first time it’s powered on. However, if I run the restart command or any similar command, the port no longer appears.
Did the “add command as reset_method”-solution solve your issue or did you find a different solution?
I have a ATMega1280 based MCU together with a Raspberry Pi Zero 2 running klipper. I experience the same issue as you and is therefore interested to know what solution you found since adding “command” as reset_method didn’t solve the issue for me.
in klippy.log I see the same error as others (see below).
I have tried multiple permutations of restart klipper service with or without the printer connected, with and without reset_method set to command or arduino etc.
The only pattern I can find is that it is not until the printer has been restarted that I can regain connection to it.
the printer is still in /dev/serial/by-id but apparently the klipper service can’t get in contact with the firmware
What to try next?
I am wondering if it is related to the fact that the USB-interface on the mightyboard is implemented in an ATmega8U2 as far as I know?
/Esben
mcu ‘mcu’: Timeout on connect
mcu ‘mcu’: Wait for identify_response
Traceback (most recent call last):
File “/home/esben/klipper/klippy/serialhdl.py”, line 68, in _get_identify_data
params = self.send_with_response(msg, ‘identify_response’)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/home/esben/klipper/klippy/serialhdl.py”, line 262, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/home/esben/klipper/klippy/serialhdl.py”, line 319, in get_response
self.serial.raw_send_wait_ack(cmds[-1], minclock, reqclock,
File “/home/esben/klipper/klippy/serialhdl.py”, line 254, in raw_send_wait_ack
self._error(“Serial connection closed”)
File “/home/esben/klipper/klippy/serialhdl.py”, line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu ‘mcu’: Serial connection closed
I have tried to change USB cable which didn’t change anything. I have also reflashed the board multiple times
I also tried using the /dev/ttyACM0
I tried to connect using both the ‘console.py’ python script as well as avrdude to try alternative connections. I didn’t succeed. I reach the same result every time: It requires a power-cycle of the MCU to connect to it again.
One thing I found out though was that avrdude cannot connect to the MCU if the baud rate set as a avrdude commandline parameter exceeds 56700 baud.
I will try to see if that information can bring me anywhere.
Still, if you have any suggestions of how to proceed or new things to test I will appreciate them a lot.
My assumption was that the connection issue had to do with the reset of the board and that it may had something to do with the way the reset is carried out maybe related to the bootloader. I thought that the bootloader on it was a standard Arduino bootloader since the board is based on a Arduino design but it seems not to be the case.
My printer is a Wanhao Duplicator 4 which is based on a variation of the mightyboard somewhere between rev E and rev G/H and it uses a special bootloader-mightyboard which the rep2/2x apparently also uses.
Thank you @Sineos for you suggestions which kept me trying to find a solution and to @dockterj for your great mightyboard work. I hope you’ll get it into the main line soon
I know that @Imesh_99 probably haven’t got a solution to his problem and won’ be able to use mine since he has a BTT board. So even though my problem is solved, the thread shouldn’t be make as solved.
I came repeatedly to a point when using very cheap USB-Hubs/Switches that after a reset it wouldn’t be working.
The exact same problem as OP is describing.
In my experience the specific USB-Switch/Hub IC called “FE1.1s” from the manufacturer TerminusTech was the single source of my failures.
Once I switched to an (also cheap) Anker USB-Hub everything is working reliable.
