I’m using heat from the bed heater for the chamber. Even if I had a separate heater for the chamber, I would still be controlling the heating element as well as the fans, so I would still want a custom control loop.
M109 and M190 are suppose to stop next gcode lines from executing until
the nozzle and bed temperatures are achieved. It is not suppose to stop the user from altering. In marlin it is possible to update M109/M190 command. It doesn’t lock the entire user interface like klipper does.
I was a marlin user, just shifted to klipper yesterday, and got stuck in this bug. In my very first print, i set the bed temperature to 110 degrees. I was taking time so i decided to set ta lower temperature again, but klipper wont allow it. I then set the bed temp to 20 degrees which after reaching 110 degree, it tried to go back to 20 degrees. there i realized that i am stuck because here the ambient temperature is height than 30 degree, so i am never going to achieve 20 degrees, and i am stuck. All i could do is restart the firmware.
It is extremely non user friendly… if u accidently typed wrong temperature (sometimes not attainable temperature as mentioned above) ur part being 3D printed is as good as gone!!!, bcz u have to restart the firmware to get out of this lock
Hello @SUNZA !
This is no bug. This is intended by Klipper:
Set extruder temperature and wait: M109 [T] S
Note: M109 always waits for temperature to settle at requested value
Set bed temperature and wait: M190 S
Note: M190 always waits for temperature to settle at requested value
from::
Klippers report temperatures (M105). And commands that ask (GET_RETRACTION) and commands that adjust (SET_GCODE_OFFSET) would have been nice if they worked. Also CANCEL_PRINT would be nice if it worked while Klipper is waiting for temperatures.
I may have still not understood, why there seems to be this fixation on the blocking variants (M109
/ M190
) instead of using the non-blocking variants (M104
/ M140
).
Yes, Klipper may be different from Marlin in this respect and yes, this might come at a surprise for new users but I have yet to see a scenario that cannot be solved with the non-blocking variants.
So it rather seems to be a matter of adapting to a new workflow than discussing about an alleged “bug”.
How can this be implemented? The printer still has to wait until the correct temperature is reached.
My approach is quite simple for the slicer starting gcode or START_PRINT
macro:
- Kick off the temperatures via
M104
/M140
- Do whatever you need, e.g. homing, heat soaking etc
- Shortly before the print starts, use the blocking variants (
M109
/M190
) to secure the temperatures
And if something really goes wrong and I need to cancel it, then I use M112
and start over. If you have properly setup your workflow, then it is not a big thing either.
You’re just trolling, aren’t you?
No, he is not.
Things work differently with Klipper than with Marlin.
I know that. And I think most people who visit here know that. But when he/she writes about fixation on the use of the M109/M190. Well then I have fixation on many gcode commands. The only thing you need is G1, right?
but dear how would you solve the problem which i mentioned in the 2nd paragraph?
even though its intentional but that problem doesn’t exist in Marlin.