G10 P0 depricated in 3.5.beta1?
-
Running 3.5.0-beta.3
on Duet2 WIFIMy slicer (Prusaslicer 2.5.2), with my custom printer (set to Reprap fw in the Printer config), emits a G10 P0 S215 to set the temperature (and, I think, set the heater to active) followed by an M116 to wait for the heater to warm up.
Today I noticed my printer did not wait for the heater to get to temperature. Looking at the extruder on DWC and testing by manually entering the G10 and M116 commands, I can see that the G10 P0 S215 does not cause the heater to switch to active. The tool is selected, so that's not the issue. I added an M568 A2 to the custom Gcode in the slicer, and this fixed the issue.
My question is whether this is behavior I should expect from G10? I'm sure if there is some other Gcode that used to be used after a G10 to turn on the heater, but Prusa slicer didn't emit it as a default.
-
@mikeabuilder there has been no deliberate change to behaviour of G10 in RRF 3.5. G10 has never caused the heater state to be set to active. Most likely, you had no tool selected, and sending T0 would have activated the heater.
-
@dc42 - Thanks for the advice. A couple weeks back, we were having an issue with not having a tool selected before a print, but we thought we had solved it through a check and select in our start.g file. I'll go back and look at this some more.
-
Not sure if it helps - but my understanding of prusaslicer is that if you include heater settings in Printer Settings --> Custoem G-Code then prusaslicer will not emit its own.
I don't have time to check now, but I recall that the current prusaslicer beta (2.6.0) includes an option to specifically inhibit heater gcodes (even if you do not set them yourself as Custom G-Code).
