Printer: K2 Plus
Firmware shown in log: c440x 1.1.4.11
Klipper log version: 09faed31
The issue is simple
After sending a print job, the printer stalled. I manually stopped the print from the K2 Plus touchscreen. The stop command was accepted, but the printer did not return to a ready state for approximately 17 minutes.
That is the user experience.
This is not theoretical. I reviewed the Klippy and Moonraker logs, and the log behavior matches what I observed in real time. I have also allowed this recovery cycle to fully play out on more than one occasion specifically to confirm whether the behavior is repeatable.
It is.
Under normal use, I would have power-cycled the printer long before waiting 17 minutes. The only reason I waited was to document the failure instead of masking it with a reboot.
Before anyone asks about firmware
Before Creality or anyone else asks, “Did you update to the latest firmware?”, that response is not acceptable by itself.
If Creality believes a firmware update fixes this, then say exactly which firmware version fixes it, what specific recovery logic was changed, and why this failure mode was allowed to exist in released firmware in the first place.
“Just update the firmware” is not a serious answer when firmware quality is part of the complaint. Users have recently reported firmware updates leaving machines inoperable, so firmware cannot be treated as a casual first-step deflection.
The question is not whether users can keep chasing the newest firmware release. The question is why a flagship printer has firmware that can accept a Stop command and then leave the printer unavailable for approximately 17 minutes.
What the logs show
The logs point to the printer getting stuck in a G28 / Z-probe / PRTouch recovery sequence after cancellation. The key errors include:
PR_ERR_CODE_G28_Z_DETECTION_TIMEOUT
G28 Z try probe out of times
ACCURACY G28 retry out of:20 times still error!!
In plain English, after pressing Stop, the printer repeatedly tried and failed to complete Z detection before finally recovering.
That is indefensible.
A flagship printer should not need 17 minutes to recover from a stopped job
If Z detection fails, the firmware should report the fault clearly, stop retrying after a reasonable limit, and return the printer to a controlled state where the user can take corrective action.
- Stop should mean stop.
- Cancel should recover cleanly.
- The user should not be locked out while the printer disappears into a probing recovery loop.
This is basic failure handling. This kind of behavior has no excuse for existing beyond beta testing. It should not be present in released firmware, and it should not still be present after the product has been in the field this long.
This is the broader Creality problem
This is what I mean by chabuduo: close enough, ship it, and deal with the complaints later.
That may be tolerable on a cheap hobby kit. It is not acceptable on a machine marketed as a flagship product.
Creality keeps releasing new products while known defects remain unresolved in machines customers already paid for. That is the real criticism. Creality is moving on to the next launch before finishing the work on the last one.
Creality’s developers need to answer this directly
-
Why has this bug been allowed to linger?
-
What specific firmware logic causes the printer to remain unavailable for approximately 17 minutes after a stop or cancel event?
-
What exactly is being changed to eliminate this failure mode from the K2 Plus firmware?
-
Is this recovery logic shared with other Creality firmware branches?
-
What is being done to prevent the same defect from carrying into other machines and future firmware releases?
This is not a random one-off failure. It appears to be a repeatable design flaw in the stop, cancel, and recovery path. It should have been caught before release, and it should have been fixed long before now.
That is how customer confidence is lost
Creality needs to do better if it wants users to trust its flagship products.