Fine Grained Heater Control

gtj0

@dc42 said in Fine Grained Heater Control:

I want to look at this again, but I don't have time right now because I have to finish RRF 2.04, RRF 3 and Duet 3 expansion board support. Please remind me in 2-3 weeks. Meanwhile, please consider the following points and let us know what you think:

Is there any point in having standby temperatures for bed and chamber heaters? The point about standby temperatures for tools is so that you can set an inactive nozzle heater to a temperature that avoids oozing but reduces the time to heat to active temperature.

Yes! If you have a large mass bed or chamber and you are going to be printing frequently over a day with different materials it's VERY handy to have a minimum temp so that the bed doesn't cool all the way down then have to come all the way back up to working temp for a specific material. I set mine to 50c which is not hot enough to cause serious burns or damage but can allow the bed to come up to 70c and higher fairly quickly.

Tool active/standby temperatures can be set without activating the tool. Is there any point in allowing bed or chamber temperatures to be set without turning the heater on, if so what is the use case?

Yes! Without a simple toggle you'd have to remember and set the active and standby temps each time. With a toggle, I can simply turn the bed heater to standby while I'm finishing up modelling and just toggle again to bring it up to the minimum working temp of 70c while I'm slicing. If I'm printing PLA (which I usually am), the bed will be ready just as I send the file to the printer. Also if you're commissioning or testing, being able to just toggle off-standby-active is a great time saver.

The whole -273 thing just doesn't make any sense. I can set my home furnace or air conditioner to "off" without changing the set points to 0 or 100.

Should the management of bed and chamber heaters be combined, and perhaps generalised in some way?

Maybe. Those can be thought of as logical functions like tools. Or maybe, get this, they are "stationary" tools.
Seriously? Maybe "environment controls"

Rather than use a mechanism to turn a tool heater off, should there be a mechanism to deactivate a tool, as opposed to putting it in standby?

Maybe but I still believe that any heater should have positive off-standby-on control regardless of how the heater is used. This give folks the most flexibility for unseen situations and and makes commissioning and testing, easier.

Given that no slicers support setting active and standby temperatures using G10, should we admit defeat and abolish the concept of standby temperatures?

No, but maybe overloading G10 with a third meaning wasn't the best way to go.
I don't know of any slicer that doesn't support start and end macros and most support layer and filament change macros. Why take a useful capability away. Maybe move it to another code that doesn't also mean "set offsets" or "retract".

This whole thing came up again because I was trying to refactor DueUI for the DSF/RRF3 without any of my patches and I've been pulling my hair out. It's really hard to set meaningful defaults when you have to get active and standby temps from different places and go though gyrations just to turn a heater off. It's be really nice to look up heater 1 and have it tell you what it's currently effective active and standby temps are and what logical function uses it.

"heaters" : {
  [
    ...
    "usedby": "heat.beds[0]",
    "effectiveSetPoints": {
        "active": 190,
        "standby": 160
    }
  ]
}

T3P3Tony

@gtj0 said in Fine Grained Heater Control:

No, but maybe overloading G10 with a third meaning wasn't the best way to go

not sure about the exact chronology but i am fairly sure that Adrian added the temperature offset meaning to G10 before some of the other ones we published to the offical record of gcodes for RepRap 3d printing (ie. the RepRap.org codes page).

@dc42 said in Fine Grained Heater Control:

Given that no slicers support setting active and standby temperatures using G10, should we admit defeat and abolish the concept of standby temperatures?

Historical arguments aside, my personal view is that having the concept of a standby temperature for a tool is essential - just because slicers are crap at implementing it does not mean its not useful. (You can use the slicer's built in scripting or set it manually).

gtj0

@T3P3Tony said in Fine Grained Heater Control:

@gtj0 said in Fine Grained Heater Control:

No, but maybe overloading G10 with a third meaning wasn't the best way to go

not sure about the exact chronology but i am fairly sure that Adrian added the temperature offset meaning to G10 before some of the other ones we published to the offical record of gcodes for RepRap 3d printing (ie. the RepRap.org codes page).

I didn't say who maybe didn't go the right way. Yeah you got me there, sorry. I just looked at reprappro/RepRapFirmware and active and standby temps are there. Doesn't seem that any other firmwares support it though. It also doesn't mean that we can't provide optional advanced and more consistent control.

gtj0

OK, I'm re-re-resurrecting this

How about this...
Add a "Q" parameter to M140/141 to set state. 0 = Off, 1 = Standby, 2 = On.
If the parameter isn't provided, assume "On" just like it is today.

Add "H" and "Q" parameters to "T" to be able to set a tool heater's state without changing the Tool's state. "H": the tool's heater number (not the global heater number), "Q": same as "M140/141". This would allow tool preheat and "keep hot" commands to be included in gcode before and after the tool is actually selected/deselected.

The "Q" and "H" designators are just suggestions. I'm open to better suggestions.

dc42

@gtj0 said in Fine Grained Heater Control:

OK, I'm re-re-resurrecting this

How about this...
Add a "Q" parameter to M140/141 to set state. 0 = Off, 1 = Standby, 2 = On.
If the parameter isn't provided, assume "On" just like it is today.

I'd rather not use Q, it's too similar to O and 0. But I agree with the principle.

Add "H" and "Q" parameters to "T" to be able to set a tool heater's state without changing the Tool's state. "H": the tool's heater number (not the global heater number), "Q": same as "M140/141". This would allow tool preheat and "keep hot" commands to be included in gcode before and after the tool is actually selected/deselected.

I'm less keen on that. RRF already has the concept of a tool being in standby mode to keep its heaters hot when it is switched from active to standby. To handle preheat, how about adding a command to set a tool to Standby if it is currently Off? The same tool command could have an option to turn a tool off if it is in standby.

gtj0

@dc42 said in Fine Grained Heater Control:

@gtj0 said in Fine Grained Heater Control:

OK, I'm re-re-resurrecting this

How about this...
Add a "Q" parameter to M140/141 to set state. 0 = Off, 1 = Standby, 2 = On.
If the parameter isn't provided, assume "On" just like it is today.

I'd rather not use Q, it's too similar to O and 0. But I agree with the principle.

How about "T" for sTate?

Add "H" and "Q" parameters to "T" to be able to set a tool heater's state without changing the Tool's state. "H": the tool's heater number (not the global heater number), "Q": same as "M140/141". This would allow tool preheat and "keep hot" commands to be included in gcode before and after the tool is actually selected/deselected.

I'm less keen on that. RRF already has the concept of a tool being in standby mode to keep its heaters hot when it is switched from active to standby. To handle preheat, how about adding a command to set a tool to Standby if it is currently Off? The same tool command could have an option to turn a tool off if it is in standby.

Yeah but that way you can't bring the heaters up to "active" temp before making the tool active and I'm not sure it's a good idea to tie the 2 states together. Let's say I'm building a fancy new tool changer and I have a gcode pre-processor. Let's also say that the pre-processor has the ability to calculate the optimal times for changing heater state so that the heaters are in the perfect state before being activated. Let's also say that the pre-processor is smart enough to know that the tool is going to be used again shortly and keep the heaters at the "active" temperature when the tool goes to standby. I will say that a tool should not allow a heater state change while it's active and that check was always my plan.

I used the "T" command because that one already changes tool states. If you want a separate one how about M1040 or M3090 or something else. You choose.

dc42

@gtj0 said in Fine Grained Heater Control:

Yeah but that way you can't bring the heaters up to "active" temp before making the tool active and I'm not sure it's a good idea to tie the 2 states together. Let's say I'm building a fancy new tool changer and I have a gcode pre-processor. Let's also say that the pre-processor has the ability to calculate the optimal times for changing heater state so that the heaters are in the perfect state before being activated. Let's also say that the pre-processor is smart enough to know that the tool is going to be used again shortly and keep the heaters at the "active" temperature when the tool goes to standby. I will say that a tool should not allow a heater state change while it's active and that check was always my plan.

So I think what you are looking for is a command to temporarily change the standby temperature of a tool heater. That temperature setting would be lost when the tool switches to active or off.

It might be reasonable to temporarily change the active temperature of a tool heater too (which would be lost when the tool goes to off or standby). But if the tool is off, I don't think changing its heater temperatures should be permitted.

gtj0

@dc42 I think temporarily changing the set temps would be a little more confusing and you'd have to save the original temps and you wouldn't be able to tell from the object model whether the temp was temporary or permanent. I wanted to be able to display the heater state separate from the tool state.

How about this... Can I go ahead with a pull request for the M140/141 change using the "T" parameter to set the state while we continue the tool heater discussion?

dc42

@gtj0 said in Fine Grained Heater Control:

@dc42 I think temporarily changing the set temps would be a little more confusing and you'd have to save the original temps and you wouldn't be able to tell from the object model whether the temp was temporary or permanent. I wanted to be able to display the heater state separate from the tool state.

How about this... Can I go ahead with a pull request for the M140/141 change using the "T" parameter to set the state while we continue the tool heater discussion?

I would rather we decided on how to handle temporary changes to the set temperature for tool heaters first, in case it affects how we control other heaters.

zapta

@dc42 said in Fine Grained Heater Control:

Is there any point in having standby temperatures for bed and chamber heaters?

Always found it to be confusing. compared to simple current target temperature and on/off. At least for in a single extruder printer like mine. Same for tool selection UI.

Would be nice to be able to eliminate the extra complexity when configuring for a simple single extruder printer.

dc42

@zapta said in Fine Grained Heater Control:

Would be nice to be able to eliminate the extra complexity when configuring for a simple single extruder printer.

That's already done, since several years ago. M109 automatically selects the first tool if no tool is selected. You can put T0 at the end of config.g to select tool 0 automatically.

The point is that RRF allows much more flexible tool and heater configuration than other firmwares do, and some types of 3D printer need this flexibility. Unfortunately, most slicers haven't caught up even after 5 years.

wilriker

@gtj0 said in Fine Grained Heater Control:

Let's also say that the pre-processor has the ability to calculate the optimal times for changing heater state so that the heaters are in the perfect state before being activated. Let's also say that the pre-processor is smart enough to know that the tool is going to be used again shortly and keep the heaters at the "active" temperature when the tool goes to standby. I will say that a tool should not allow a heater state change while it's active and that check was always my plan.

That's exactly what the pre-processor of Diabase does. It (mis)uses standby temp for this purpose, i.e. when time has come for a tool to preheat it will edit standby temp to active temp and insert appropriate commands to restore actual standby temp when the tool is deselected.

zapta

@dc42 said in Fine Grained Heater Control:

You can put T0 at the end of config.g to select tool 0 automatically.

Yes, I have it at the end of my config.g but sometimes, when I do manual operations via PanelDue I need to select the tool to get it heating up. Not sure what got it to get deselected.

With a single tool, it would be nice to be able to hide the concept of tool selection for a more intuitive PanelDue/Web user experience with a single tool machine. In a sense, it's an unnecessary leak of complexity from more complex machines.

gtj0

@wilriker said in Fine Grained Heater Control:

@gtj0 said in Fine Grained Heater Control:

Let's also say that the pre-processor has the ability to calculate the optimal times for changing heater state so that the heaters are in the perfect state before being activated. Let's also say that the pre-processor is smart enough to know that the tool is going to be used again shortly and keep the heaters at the "active" temperature when the tool goes to standby. I will say that a tool should not allow a heater state change while it's active and that check was always my plan.

That's exactly what the pre-processor of Diabase does. It (mis)uses standby temp for this purpose, i.e. when time has come for a tool to preheat it will edit standby temp to active temp and insert appropriate commands to restore actual standby temp when the tool is deselected.

Yeah and I'd prefer to not mis-use standby temp and have to keep track of the previous value. I simply want to change state without having to maintain "state" externally.

zapta

@dc42, here is an example of what I said earlier. This is a single extruder machine, the active temp is set to 240 but the hotend doesn't heat because it's not selected.

gtj0

@dc42 So where does that leave us? Temporarily changing standby temps seems like a complicated hack to me when all I want to do is change heater state.

@zapta Can you describe in more detail what behavior would you like to see for single-tool single-heater printers?

jay_s_uk

you can select the hot end from paneldue by clicking on its icon.

zapta

@gtj0 said in Fine Grained Heater Control:

@zapta Can you describe in more detail what behavior would you like to see for single-tool single-heater printers?

Basically similar UI model most single head printers have. Something along this lines

Nozzle: current temp, target temp.
Bed: current temp, target temp.

Target temp of 0 indicates off. Turning heaters on/off is done by controlling the target temp. No concept of 'tool selection' as there is only one tool. No concept of standby.

Everything above is about the UI aspects that are exposed to the operator, not the internal model or gcodes.

gtj0

@zapta said in Fine Grained Heater Control:

@gtj0 said in Fine Grained Heater Control:

@zapta Can you describe in more detail what behavior would you like to see for single-tool single-heater printers?

Basically similar UI model most single head printers have. Something along this lines

Nozzle: current temp, target temp.

Bed: current temp, target temp.

Target temp of 0 indicates off. Turning heaters on/off is done by controlling the target temp. No concept of 'tool selection' as there is only one tool. No concept of standby.

Everything above is about the UI aspects that are exposed to the operator, not the internal model or gcodes.

OK, well that can be solved in the UIs however this discussion winds up.