M104 with inactive tool puts heater in standby mode
-
The problem is that M104 and M109 are not fit for purpose. They were OK when 3D printers had only one extruder. They are sort of OK when each tool has exactly one heater that is not shared with any other tools. But for more complex situations, including mixing extruders (different tools share the same heater) and tools with multiple heaters (e.g. tools that use pellet hoppers, so there is a 2-stage melting process), they don't work.
RepRapFirmware implemented a solution way back in 2013. Instead of using commands to control tool heaters directly, use commands to specify the active and standby temperatures on a per-heater per-tool basis. Then when a tool is selected, RRF heats up its heaters to active temperature. When a tool is deselected, RRF starts cooling its heaters down to standby temperature. The slicer doesn't need to know the details of how the tools are arranged, it just needs to know the tool numbers you want to use and what active and standby temperatures you want to use for them.
This approach solves the problem, although I would have preferred it if the command to set tool temperatures wasn't G10 because that already had meaning in CNC machines, and it now also has a totally separate meaning in 3D printers (firmware retraction).
Unfortunately, most slicers persist in using M104 and M109 even when the target is RepRapFirmware. Worse, most of them don't even select a tool when they start heating. This means that when RRF receives M104 and M109 commands, RRF has to second-guess what the slicer is trying to do. That's why, when it receives M109 with a T parameter, it makes that tool active; and when it receives a M109 command with no T parameter and there is no active tool, it looks for a default tool to activate.
The real solution is for slicers to stop generating M104 and M109 commands when targeting RepRapFirmware, and to use G10 commands to set active and standby temperatures instead. There is one scenario that isn't covered by this approach: when targeting a dual-nozzle machine, Cura anticipates a tool changes and sends a M104 command to pre-heat the new tool to active temperature. I could add support for this in RRF by adding a new command meaning "start heating tool N to its active temperature".
Meanwhile, the only thing I can think of doing to help is to change the response to M104 so that if M104 has a T parameter which is not the active tool, then any heaters associated with that tool that are also used by the current tool are not altered.
-
That's all understood, @dc42 but I am not going to work on a G10 solution for Cura right now. Maybe in the future.
In the meantime, I'm adding a setting that makes Cura aware that the extruders share a heater and in that situation it won't issue any M104 or M109 gcodes for the non-active extruders. It won't do any ramp up/down of the non active extruders (obviously). It will simply issue a M109 when it has switched to an extruder whose temperature is different from that specified by the last M109 gcode issued.
-
@burtoogle. I think this will work. I need to slice a few models to make sure.
-
If duet folks are interested in trying what was built as a proof that this would work: https://github.com/smartavionics/Cura/issues/8 is a feedback place with builds that add this feature in to a test version of Cura.
It adds in a checkbox to mark the printer as having a shared heater.
The checkbox then alters / blocks the behaviour of any temp change calls which would adversely affect the currently selected tool. Is that right @burtoogle ?
- Please test, feedback and comment in smartavionics GitHub directly if you get a chance to test.
I have been printing all day - small models which turn off various tools and change the temp of different tools all good for me.
