-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
M109 S always waits for cooldown #1474
Comments
Try m109 S instead of R I.e. m109 S60, not m109 R60 |
Thanks, it's nice to see that Marlin implements this already. Unfortunately it appears to be broken in the Prusa firmware, as it will still wait for cooldown. |
Weird it's working for me? Unless I'm not understanding what you're trying
to do
…On Wed, Jan 23, 2019, 3:59 AM haarp ***@***.*** wrote:
Try m109 S instead of R
Thanks, it's nice to see that Marlin implements this already.
Unfortunately it appears to be broken in the Prusa firmware, as it will
still wait for cooldown.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1474 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARpg5CXYWIuN4v3Qwuvl6NyTnAbbHm4sks5vGCRvgaJpZM4aNniG>
.
|
Weird indeed. Reproduction:
If M109 S worked as intended, the beep should immediately follow the M109 S150 command. |
Okay, I had a look at the code, https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp#L5529 Both M109 and M190 set CooldownNoWait=true when S is specified, however only the bed temperature actually uses that variable. Therefore only the bed temperature can actually use the S feature, while the extruder will invariably wait for cooldown. |
Err, I was partially wrong. The culprit is TEMP_RESIDENCY_TIME. If that is defined, which it is by default, wait_for_heater() will ignore CooldownNoWait, and always wait despite the S parameter being used for M109. https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Marlin_main.cpp#L7829 |
This bug is still present in 3.7.2. |
Can't you just use M104 S0? That way the printer won't have to execute the M109 command to completion. You can set it to cooldown but it'll immediately move on to the next gcode and can be interrupted by commands other than M0/M1. |
This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment. |
This issue has been closed due to lack of recent activity. |
Hello,
I'd like to file a feature request. Very frequently I see start g-codes that first heat up the nozzle and bed to an intermediary temperature, then start mesh bed levelling, then wait for the final printing temperature to be reached. This is pretty clever as it saves some time and prevents oozing during bed levelling.
It doesn't work so well when you are printing several jobs in a row. The nozzle and bed will still be hot, so M109 and M190 will wait for them to cool down before continuing, only for the job to heat them up again immediately afterwards.
My proposal is to add a parameter to M109 and M190 that tells the printer to wait for both to heat up, but if the current temperature exceeds the requested temperature, simply continues without pausing.
Thank you!
The text was updated successfully, but these errors were encountered: