Fine grained heater control

dc42

What is your reason for wanting to switch a heater to active or standby temperature independently of selecting/deselecting a tool?

gtj0

@dc42 said in Fine grained heater control:

What is your reason for wanting to switch a heater to active or standby temperature independently of selecting/deselecting a tool?

Specifically thinking of non-tool heaters like beds, chambers, etc but also could be for offline tools. Having 1 set of commands for all heaters would make things a little less "inferred" about how to control a heater and its state.

dc42

There is already M144 to set the bed heater to active or standby, but I agree that Off would be a useful option too. Currently there is no similar option for chamber heaters.

gtj0

@dc42 would you be open to a pull request for a new M code?

M308 Generic Heater Control
Pnnn Heater number
Snnn Active Temp
Rnnn Standby Temp
Tnnn State: 0 = off, 1 = standby 2 = on.

dc42

@gtj0 said in Fine grained heater control:

@dc42 would you be open to a pull request for a new M code?

M308 Generic Heater Control
Pnnn Heater number
Snnn Active Temp
Rnnn Standby Temp
Tnnn State: 0 = off, 1 = standby 2 = on.

You will need to specify how it is supposed to interact with other M-codes, e.g.:

If the heater is used as a tool heater, what happens when that tool is made active, or made inactive?
If that heater is assigned as a bed or chamber heater, what happens when a normal bed or chamber heater command is received (e.g. M140, M141, M190, M191)?

mrehorstdmd

@gtj0 I use macros to set the chamber heater temperature to 50C for ABS printing, 35C for PLA, and 0 to turn it off. I also have preheating macros for ABS, PLA, and TPU that set all the heaters to appropriate temperatures. It will be nice when the PanelDue firmware eventually includes the chamber heater on the graphical controls, but until then, macros work fine.

gtj0

@dc42 said in Fine grained heater control:

@gtj0 said in Fine grained heater control:

@dc42 would you be open to a pull request for a new M code?

M308 Generic Heater Control
Pnnn Heater number
Snnn Active Temp
Rnnn Standby Temp
Tnnn State: 0 = off, 1 = standby 2 = on.

You will need to specify how it is supposed to interact with other M-codes, e.g.:

If the heater is used as a tool heater, what happens when that tool is made active, or made inactive?

If that heater is assigned as a bed or chamber heater, what happens when a normal bed or chamber heater command is received (e.g. M140, M141, M190, M191)?

No change to either behavior. The M308 commands would be an additional way to control the heater. The only interaction between the old and new would be that you couldn't turn off or set a heater to standby if it were associated to a tool and that tool were active. I don't think there are any other conflicts.

@mrehorstdmd said in Fine grained heater control:

@gtj0 I use macros to set the chamber heater temperature to 50C for ABS printing, 35C for PLA, and 0 to turn it off. I also have preheating macros for ABS, PLA, and TPU that set all the heaters to appropriate temperatures. It will be nice when the PanelDue firmware eventually includes the chamber heater on the graphical controls, but until then, macros work fine.

The new command should facilitate better heater support in PanelDue firmware, DWC and something else I'm working on. It allows heaters to be controlled without having to know whether it's a bed, chamber, hot end, seat warmer, etc.

gtj0

There's a pull request up for the new M308 command. Here's the help/description.
Feedback welcomed.

    M308: Generic Heater Control

    Parameters:

     * Pnnn Heater index
     * Snnn Target active temperature  (note 1,3)
     * Rnnn Target standby temperature  (note 1,3)
     * Tnnn Heater state: 0 = off, 1 = standby 2 = on. (note 2,3)
    
    This command allows direct control of heaters without having
    to know whether a heater is a bed, chamber, tool or some other
    type of heater.  It does not replace any existing G or M code
    commands and is meant more for use from the command line and
    by user interfaces.  Although nothing prevents it, this command
    should not be used by slicers. They should continue to use the
    standard control commands.
    
    The P parameter is required and selects the heater.  There is no
    default so the minimum command is M308 Pnnn which prints the
    heater's current state, target active temperature, target standby
    temperature and the current temperature as follows:
        
    Heater 1 State: 'Off', Active temp: 225.0°, Standby temp: 190.0°,
    Surrent temp: 23.2°"
        
    The S and R parameters are optional and set the target active and
    standby temperatures.
    
    The T parameter is also optional and if supplied, sets the heater's
    current state where 0 = off, 1 = standby 2 = on.
    
    Examples:
     * M308 P0 S70 R50
       Set heater 0 (usually but not necessarily the bed) target
       active temperature to 70 and the target standby temperature
       to 50.  Since the T parameter is not supplied, the heater's
       current state is not altered.
    
     * M308 P0 T1
       Set heater 0 to standby.  Any previously set standby temperature
       is preserved, even if set by another command such as M140, M141,
       G10, etc.
    
     * M308 P1 S225
       Set heater 1 (an extruder maybe) target active temperature to
       225 leaving its target standby temperature and state alone.
    
    Notes:
    (1): Since the T parameter explicitly controls the state of the
         heater, no special importance is placed on temperatures less
         than -273.  They will NOT turn the heater off as they may in
         other commands.
    
    (2): To prevent accidental disruption of a print, you can change
         the target temperatures of a heater assigned to the active
         tool but you cannot change its state.
    
    (3): This command will return an error if an attempt is made
         to set the temperatures or state of a heater in "fault"
         or "tuning" state.  Use the appropriate commands to return
         the heater to a working state before re-issuing this command.

gtj0

@dc42 in this post..
https://forum.duet3d.com/topic/9299/m104-with-inactive-tool-puts-heater-in-standby-mode/34

You say "... I'm not convinced that it makes any sense for heaters (as distinct from tools) to have separate states for active and standby."

Is that what's holding up your merge of this commit? Having separate states for bed and other non tool heaters makes perfect sense to me especially if you have high power bed or chamber heaters that you can drop the temperature on between prints or multiple bed heaters where you want to keep the current print area hot but let the non-print areas cool down a bit without getting cold. Or did I misunderstand your comment?

dc42

@gtj0 said in Fine grained heater control:

@dc42 in this post..
https://forum.duet3d.com/topic/9299/m104-with-inactive-tool-puts-heater-in-standby-mode/34

You say "... I'm not convinced that it makes any sense for heaters (as distinct from tools) to have separate states for active and standby."

Is that what's holding up your merge of this commit? Having separate states for bed and other non tool heaters makes perfect sense to me especially if you have high power bed or chamber heaters that you can drop the temperature on between prints or multiple bed heaters where you want to keep the current print area hot but let the non-print areas cool down a bit without getting cold. Or did I misunderstand your comment?

What's holding me up in general workload, plus I am uneasy at accepting changes that have complex interactions with the rest of the system, until I have thought through all the consequences that I can foresee.

For some time I have been unhappy with the way that temperatures are managed in RRF. Tools have active and standby states, and associated temperatures. This makes perfect sense, because the active and standby temperatures are used by automatic functions, i.e. tool changes. OTOH having both active and standby states and temperatures for the actual tool heaters doesn't make sense to me, because the active/standby context belongs to the tool context, not the heater context as well.

When it comes to bed and chamber temperatures, the first question is whether we really need standby temperatures. There is a "Bed standby" GCode, but does anyone actually use it? Is there a reason why you would have your slicer send "Bed standby" and "bed active" commands, rather than just setting the temperature? There is no "Chamber standby" GCode.

I can see that you might possibly want to have the bed and chamber temperatures selected according to the filament you have loaded, in which case you might want to select the temperatures in the filament macros and just on/off/standby in the slicer. This would preclude using different values for different layers. But if you did want to do that, I still think that controlling them at the level of individual heaters is the wrong approach. You would want to set the entire bed system or entire chamber heater system (each possibly comprising multiple heaters) to standby, or on. So I think a better approach would be to allow the bed and the chamber heater subsystems to be treated rather like tools, so that you could set active and standby temperatures for each of the individual heaters in the bed heater subsystem or the chamber heater subsystem, and then switch the entire bed or chamber subsystem to active, standby or off.

What is the use case that prompted you to suggest M308?

gtj0

What always bothered me about the current arrangement was that you can't simply set the state of a "heater" regardless of what it's being used for (if anything). The fact that heaters are a low level construct in RRF is great but we don't have any way to access them as such via GCode. From a slicer perspective this may be OK but from a UI perspective it isn't really. Having to turn a heater off by setting it's temperature to -273 for instance, is an issue because now you've lost the original set point and it's left to the UI to keep track. What if there are multiple UI instances running though? From a UI design perspective it's much cleaner and easier to work with heaters as heaters. The M308 command allows the decoupling so we're not dealing with "but I don't want the tool state to change with heater state" or "but I don't want heater state to change with tool state" thing. To be clear though, the addition of M308 doesn't change any existing behavior. No one's forced to use it.

Those of us who fall in the "20%" of the "80/20" user population would also like to have more control when we're tuning , testing, upgrading or building printers instead of actually printing. Heck, I have a heater in my filament dispenser box. It's not a bed, chamber or tool but I'd still like to control it.

dc42

@gtj0 said in Fine grained heater control:

Having to turn a heater off by setting it's temperature to -273 for instance, is an issue because now you've lost the original set point and it's left to the UI to keep track.

Agreed. For tool heaters, IMO what's missing is a mechanism to turn a tool off. Turning a tool off would turn off all its heaters, except for those that are also used by other tools which are active or on standby. For bed and chamber heaters, I think we need at least on/off states. Possibly also Standby, although I'm less sure if that's needed.

To be clear though, the addition of M308 doesn't change any existing behavior. No one's forced to use it.

True, as long as users realise that any use of M308 is likely to get overridden by some other operation, e.g. a tool change. In that sense it's a low level debugging aid, rather like G1 S2 individual motor moves.

Heck, I have a heater in my filament dispenser box. It's not a bed, chamber or tool but I'd still like to control it.

What I had in mind was to add the concept of "Environment temperature controller". Each would have one or more associated heaters. The bed would be one such controller, the chamber another, and there would be options to add others such as your filament dispenser box. Each controller would have Off and Active states, also Standby if users think it would be useful.

This scheme ( a "Turn tool off" command + environment temperature controllers) would obviate the need to have M308 for the purpose of turning heaters off. It might still be useful to provide M308 as a debugging aid.

gtj0

@dc42 said in Fine grained heater control:

@gtj0 said in Fine grained heater control:

Having to turn a heater off by setting it's temperature to -273 for instance, is an issue because now you've lost the original set point and it's left to the UI to keep track.

Agreed. For tool heaters, IMO what's missing is a mechanism to turn a tool off. Turning a tool off would turn off all its heaters, except for those that are also used by other tools which are active or on standby. For bed and chamber heaters, I think we need at least on/off states. Possibly also Standby, although I'm less sure if that's needed.

The standby states are good for items that take a relatively long time to come up to full temperature so you want to turn them down between prints to save power but not have to wait for them to come up to full temp for use. It's just easier to configure an active and standby set point then switch between them rather than having to raise and lower the temperature. A good example of this is a print-end script that can just say "put the bed to standby" and not have to worry about an actual temp. This way if you have multiple printers it's easier to configure each printer with a bed standby temp appropriate for it and not have to change the print-end script.

To be clear though, the addition of M308 doesn't change any existing behavior. No one's forced to use it.

True, as long as users realise that any use of M308 is likely to get overridden by some other operation, e.g. a tool change. In that sense it's a low level debugging aid, rather like G1 S2 individual motor moves.

Yeah I'll buy that.

Heck, I have a heater in my filament dispenser box. It's not a bed, chamber or tool but I'd still like to control it.

What I had in mind was to add the concept of "Environment temperature controller". Each would have one or more associated heaters. The bed would be one such controller, the chamber another, and there would be options to add others such as your filament dispenser box. Each controller would have Off and Active states, also Standby if users think it would be useful.

This scheme ( a "Turn tool off" command + environment temperature controllers) would obviate the need to have M308 for the purpose of turning heaters off. It might still be useful to provide M308 as a debugging aid.

OK I see where you're going in general and I'm good with it. As long as we can remove the ambiguity and not confuse the hell out of people with different commands and different values depending on which type of controller they're trying to manipulate.

I wonder though, about these cases and if they're even valid:
An active tool with 1 heater in "active" state and another in "standby" state.
A standby tool with active heaters that aren't part of the active tool.

I guess I'm asking if we need to allow a user to specify an arbitrary state relationship between tools and heaters?
When tool 0 is selected, heater 1 is active and heater 2 is standby.
When tool 0 is deselected, heater 1 is standby and heater 2 is active.
When tool 1 is selected, heater 1 is off and heater 3 is active.
etc.

dc42

@gtj0 said in Fine grained heater control:

I wonder though, about these cases and if they're even valid:
An active tool with 1 heater in "active" state and another in "standby" state.
A standby tool with active heaters that aren't part of the active tool.
I guess I'm asking if we need to allow a user to specify an arbitrary state relationship between tools and heaters?
When tool 0 is selected, heater 1 is active and heater 2 is standby.
When tool 0 is deselected, heater 1 is standby and heater 2 is active.
When tool 1 is selected, heater 1 is off and heater 3 is active.
etc.

This is part of the reason why I want to do away with active and standby states of individual heaters. There would be only on and off states, and the rule would be:

If the active tool uses a heater, that heater is set to the active temperature of that tool;
Else if a tool on standby uses that heater, it is set to the standby temperature of the last tool using it that was switched to standby;
Else it is off (zero degrees set point).

gtj0

@dc42 said in Fine grained heater control:

@gtj0 said in Fine grained heater control:

I wonder though, about these cases and if they're even valid:
An active tool with 1 heater in "active" state and another in "standby" state.
A standby tool with active heaters that aren't part of the active tool.
I guess I'm asking if we need to allow a user to specify an arbitrary state relationship between tools and heaters?
When tool 0 is selected, heater 1 is active and heater 2 is standby.
When tool 0 is deselected, heater 1 is standby and heater 2 is active.
When tool 1 is selected, heater 1 is off and heater 3 is active.
etc.

This is part of the reason why I want to do away with active and standby states of individual heaters. There would be only on and off states, and the rule would be:

If the active tool uses a heater, that heater is set to the active temperature of that tool;

Else if a tool on standby uses that heater, it is set to the standby temperature of the last tool using it that was switched to standby;

Else it is off (zero degrees set point).

Seems to me that makes it more confusing rather than less. I'd think that if a tool has multiple heaters, you may need to set each heater to separate temperatures maybe for different materials. It would think that it'd actually be easier from a development perspective to allow generic mappings and let the user combine them however they want rather than hard coding the rules. Hmmm.