Attempted to print this model on my Geeetech A10 with BMG extruder and ran into this error. I am on a pretty recent version of Klipper v0.10.0-319-g3e0c0e9c. After doing lots of googling, reading the github issues and searching this forum - I have not found a solution. My suspicion is this might be a bug? I was able to print a calibration cube with no issues.
Have attached klippy.log, printer.cfg and gcode.
klippy.log (2.6 MB)
printer.cfg (6.1 KB)
GA10_rpi-box.gcode.zip (3.1 MB)
Gcode for the box I was printing in separate reply as I wasnt allowed to attach more than 2 items.
Check your logs:
Timeout with MCU 'mcu' (eventtime=126700.692747)
Transition to shutdown state: Lost communication with MCU 'mcu'
is a few lines above the error: Internal error in MCU 'mcu' stepcompress. So this error is a symptom / consequence of the lost MCU connection.
No indication thou as to why the connection was lost. Can be multiply reasons, from bad cabling, EMI, hardware defects etc.
Is it possible to enable retries or something like that with Klipper comms to the MCU? As I have had some issues like this in the past.
Unfortunately this is not possible.
Between the host and the MCU there are very strict timing requirements. Once the two get out of sync due to connection problems, Klipper will react with a fatal error.
This might be incorrect, but looking through the Klipper MCU firmware and how it communicates with the host. It seems that it is essentially a RPC based system, with time syncing. When 4 clock sync messages build up in the queue, the connection is considered timed out.
I am wondering if its possible to have enough steps to compress that you would block the serial port from being able to process other commands such as clock sync above and cause the host program to think the connection has died?
Generally the core of Klipper is the communication between host and MCU. From what I can tell this works very reliable, otherwise the support channels would be full of issues.
Band-aiding ramshackle hardware with software is not the way to go, although typically taken as the first and foremost solution.
Any details on the precise inner workings would have to be answered by the core developers.
Not trying to be rude, but also “band aiding ramshackle hardware with software” makes no sense in the context of the potential issue i raised. If you don’t understand what I am talking about then just say so or dont reply.
If you are experiencing such hard faults, it is most likely attributable to your hardware. Unfortunately most of time people with issues call for software improvements (which is working on countless instances) to cover up for some hardware issues.
This in turn leads to more complex software that someone needs to write and maintain and even may introduce other issues that were not present before. Especially when working on very central functions of the system.
In any case you are happily invited to improve this system and propose a better solution in a pull request on Github.