M0, still not working, to cancel heater PID tuning

gnydick

Tuning a hot end heater typically takes between five and ten minutes. Tuning a bed heater may take more than half an hour, depending on the thermal capacity of the bed. You can cancel tuning by sending M0.

I've searched this forum and this issue goes back at least 8 years.

I tried cancelling a heater tuning and it said I had to pause my print first, when obviously there is no print during M303.

droftarts

@gnydick That sentence seems to have come from the old Dozuki site. I can only find one mention (searching for "M303 M0" in titles and posts), from May 2022 about it not working (though doesn't mention which firmware version), so it's possible it used to in earlier RRF versions. What thread did you find that was 8 years old?

This thread reported the problem, so it's on the list to look at: https://forum.duet3d.com/topic/30848/unexpected-behaviour-3-5-0b1
The only way to cancel M303 currently is with an emergency stop.

There is a general problem with how cancelling macros is handled and what state the machine is left in, and 'system' macros/routines such as M303 and M29 are possibly even trickier to handle. See https://github.com/Duet3D/RepRapFirmware/issues/765

After talking to @dc42, I've raised a feature request that cancelling M303 is added to M108: https://github.com/Duet3D/RepRapFirmware/issues/1010

For now, I've removed that M0 can cancel M303 from that page, and changed it to "Tuning can be cancelled with an emergency stop." The M303 entry in the Gcode dictionary also does not say it can be cancelled with M0.

Ian

T3P3 created this issue in Duet3D/RepRapFirmware

open Allow aborting macros Including homing moves - "not quite an emergency, but STOP" #765

droftarts created this issue in Duet3D/RepRapFirmware

open [FeatureRequest] Add M303 cancelling to M108 #1010

gnydick

@droftarts Thank you for following up.

Control of the command pipeline, for lack of the exact phrase, is a common thread in bugs. I don't know enough to even be dangerous with the code for the firmware, but I wonder if there's not a different approach for a future version that focuses on command flow control.