Skip to content
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

Closed
haarp opened this issue Jan 22, 2019 · 10 comments · May be fixed by #2060
Closed

M109 S always waits for cooldown #1474

haarp opened this issue Jan 22, 2019 · 10 comments · May be fixed by #2060

Comments

@haarp
Copy link

haarp commented Jan 22, 2019

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!

@Photogad
Copy link

Try m109 S instead of R

I.e. m109 S60, not m109 R60

@haarp
Copy link
Author

haarp commented Jan 23, 2019

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.

@Photogad
Copy link

Photogad commented Jan 23, 2019 via email

@haarp
Copy link
Author

haarp commented Jan 23, 2019

Weird it's working for me? Unless I'm not understanding what you're trying to do

Weird indeed. Reproduction:

  • Connect via serial interface
  • Send M109 S200 imediately followed by M300
  • printer waits until hotend reaches 200°C, then beeps

  • Send M109 S150 immediately followed by M300
  • printer waits until hotend cools to 150°C, then beeps

If M109 S worked as intended, the beep should immediately follow the M109 S150 command.

@haarp
Copy link
Author

haarp commented Jan 23, 2019

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.

@haarp
Copy link
Author

haarp commented Jan 23, 2019

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

@haarp haarp changed the title Feature Request: M109 and M190 but wait only for heat up M109 S always waits for cooldown Jan 23, 2019
@haarp
Copy link
Author

haarp commented Jun 30, 2019

This bug is still present in 3.7.2.

haarp added a commit to haarp/Prusa-Firmware that referenced this issue Jul 30, 2019
@Cloud-Galaxyman
Copy link

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.
Am I totally missing something?

erik434 pushed a commit to erik434/Prusa-Firmware that referenced this issue Feb 22, 2022
erik434 pushed a commit to erik434/Prusa-Firmware that referenced this issue May 9, 2022
3d-gussner pushed a commit to haarp/Prusa-Firmware that referenced this issue Aug 2, 2023
@github-actions
Copy link

github-actions bot commented Sep 7, 2023

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.

@github-actions
Copy link

This issue has been closed due to lack of recent activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants