M109 and M190 S waits are treated as R waits

[richfelker]

In klippy/extras/heaters.py, check_busy used absolute value to compare temp with target and also waits for PID loop stabilization. This results in waiting for cooldown as well as heating, which is the function of M{109,190} Rnnn commands, not M{109,190} Snnn ones. The PID loop wait also makes prints take gratuitously long to start; assuming you'll be doing priming/skirt/etc. there's plenty of time for it to stabilize once printing starts.

Is it desirable to have the R behavior as well as S? If not, I can submit a trivial PR to make the waits always behave as S, but it'll take a little more work to add a distinct R form.

[klipper-gitissuebot]

Hi @richfelker,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[richfelker]

This issue is filed based on reading of the source, and already contains an analysis of the mechanism of the unexpected behavior. It's not specific to any print/log.

[KevinOConnor]

This looks like a dup of #1108 .

-Kevin

[richfelker]

Yep, sorry I missed that.

[denunzio11]

I left this comment in the referenced closed issue but I'll repeat it here for what it's worth...

I'd like to add my support for this request. As someone who prints commercially, time is a factor. The extra several minutes I have experienced waiting for my printers to start their run is punishing (in the wallet). I know this sounds like an exaggeration but I print objects that have several pieces and some have shorter printing times. Adding minutes to each print adds up...I can only imagine what it would do to a farm environment. Just my 2 cents.

Or put more practically, waiting over 5 minutes for the print to start because your bed is 72 degrees instead of 70 is silly :)

[github-actions]

Hello,

It looks like there hasn't been any recent updates on this
Klipper github issue. If you created this issue and no
longer consider it open, then please login to github and
close the issue. Otherwise, if there is no further activity
on this thread then it will be automatically closed in a few
days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[richfelker]

Pinging this as not-abandoned. Would a PR that keeps the old behavior as R and changes the behavior for S be open to consideration? If so I'll prepare one soon.

[ld3300]

I can't test this now as my printer is in the middle of a long print, but this might be doable with just gcode macros. Something like:

[gcode_macro HEATUP]
gcode:
    PAUSE
    M104 S{minimum desired temp}
    UPDATE_DELAYED_GCODE ID=TEMP_CHECK DURATION=5

[delayed_gcode TEMP_CHECK]
gcode:
    {% if printer.extruder.temperature >= (minimum desired temp) %}
        RESUME
    {% else %}
        UPDATE_DELAYED_GCODE ID=TEMP_CHECK DURATION=5
    {% endif %}

[KevinOConnor]

Would a PR that keeps the old behavior as R and changes the behavior for S be open to consideration?

I commented on this recently at: #1108 (comment) . I think we should move any further discussion to the existing #1108 .

-Kevin

[KevinOConnor]

Closing this in favor of the existing #1108 .

-Kevin